Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Sigh, build is broken again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Sigh, build is broken again
Date: 1998-10-28 16:02:25
Message-ID: 17909.909590545@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-28 16:06:15
Subject: Re: [HACKERS] Open 6.4 items
Previous:From: Bruce MomjianDate: 1998-10-28 15:58:40
Subject: Re: [HACKERS] s_lock.h line 178

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group