Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> I guess the right fix is for configure to check for *both*
>> snprintf and vsnprintf --- anyone see a problem with that?
> Oops, that was me, today. Patch attached. This is not the time to be
> adding new portability calls.
> Comments on how to handle this?
There are two ways we can look at this:
1. It's a simple oversight in configure, trivially fixable (need to
build snprintf.o if *either* snprintf or vsnprintf is missing).
2. We have never used vsnprintf before (if we had, the build would've
failed for me before). So, if we let the new trace code stand, we
are depending on untested emulation code in snprintf.c and/or system
library routines of unproven reliability.
Ordinarily I'd go for view #1 without a second thought ... but when
we're only four days before a major release, view #2 has to be taken
seriously. The risk may be low, but there's not time to gain confidence
that vsnprintf is dependable.
Marc's opinion appears to be that we should just revert the code;
the buffer-overrun bug is presumably of long standing, so people can
live with it a while longer. I think I agree with him.
So, my vote is to back out the trace.c patch, and re-apply as soon as
6.4 is out. I'll add the necessary stuff to configure at that time too.
regards, tom lane
