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

Re: (yet) more buffer paranoia

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: (yet) more buffer paranoia
Date: 2002-08-24 11:31:47
Message-ID: 200208241131.g7OBVmM14664@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I guess the question is where there are tons more.  If not, I think it
> > would be wise to just clean it up so any future uses will look out of
> > place.
> 
> Should I point out that Neil already managed to break the regression
> tests on the eve of an emergency patch-release with a completely
> unnecessary snprintf-ization of show_datestyle?
> 
> There *are* risks in changing working code, and while those risks may be
> small, I don't see the point of taking them in places where the benefit
> is provably zero.  If it's not obvious that a sprintf or similar can't
> overflow its buffer, then by all means make it snprintf instead.  But
> I don't hold with the idea that sprintf is ipso facto bad.

Yes, but by changing them, we mark the calls as not having to be
reviewed in the future.  That seems like a maintenance gain to me. Some
of our security patches for 7.2.2 related to sprintf problems, right, so
it is a known risk and deserves to be audited.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2002-08-24 21:09:55
Subject: Re: pg_attribute.attisinherited ?
Previous:From: Neil ConwayDate: 2002-08-24 05:04:12
Subject: Re: (yet) more buffer paranoia

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