Обсуждение: Sigh, build is broken again
Someone checked in code that assumes vsnprintf() exists.
Should be cool, we have an emulation right? Well, no.
configure sets up to build port/snprintf.c if snprintf()
doesn't exist. HPUX, for one, has that but not vsnprintf.
I guess the right fix is for configure to check for *both*
snprintf and vsnprintf --- anyone see a problem with that?
regards, tom lane
> Someone checked in code that assumes vsnprintf() exists. > > Should be cool, we have an emulation right? Well, no. > configure sets up to build port/snprintf.c if snprintf() > doesn't exist. HPUX, for one, has that but not vsnprintf. > > 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? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 27 Oct 1998, Tom Lane wrote:
> Someone checked in code that assumes vsnprintf() exists.
>
> Should be cool, we have an emulation right? Well, no.
> configure sets up to build port/snprintf.c if snprintf()
> doesn't exist. HPUX, for one, has that but not vsnprintf.
>
> I guess the right fix is for configure to check for *both*
> snprintf and vsnprintf --- anyone see a problem with that?After v6.4 is released, sounds great to me...before, I send
guys
around to break fingers :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Tue, 27 Oct 1998, Bruce Momjian wrote:
> > Someone checked in code that assumes vsnprintf() exists.
> >
> > Should be cool, we have an emulation right? Well, no.
> > configure sets up to build port/snprintf.c if snprintf()
> > doesn't exist. HPUX, for one, has that but not vsnprintf.
> >
> > 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?
Ya...back it out until after v6.4 is released, and then we will
handle it then *major glare*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
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
> 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. Already done. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Is this item resolved? > Someone checked in code that assumes vsnprintf() exists. > > Should be cool, we have an emulation right? Well, no. > configure sets up to build port/snprintf.c if snprintf() > doesn't exist. HPUX, for one, has that but not vsnprintf. > > I guess the right fix is for configure to check for *both* > snprintf and vsnprintf --- anyone see a problem with that? > > regards, tom lane > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Is this item resolved?
>> Someone checked in code that assumes vsnprintf() exists.
>>
>> Should be cool, we have an emulation right? Well, no.
>> configure sets up to build port/snprintf.c if snprintf()
>> doesn't exist. HPUX, for one, has that but not vsnprintf.
>>
>> I guess the right fix is for configure to check for *both*
>> snprintf and vsnprintf --- anyone see a problem with that?
No, we backed out the original patch and thus made the problem go away
for 6.4. That's where it still stands, AFAIK.
I'd suggest re-committing the original patch (something to do with
tracing, IIRC) but to the 6.5 branch *only*. The argument about not
having done enough testing applies even more strongly to 6.4.1 than
it did for 6.4. But if we put it into 6.5 now, we should have some
track record with vsnprintf before 6.5 hits the streets.
As soon as you commit the trace patch, my build will break, and then
I'll do something about fixing configure to check for vsnprintf ;-)
regards, tom lane