[Zlib-devel] gzprintf() bug/"feature"

[Greg Roelofs]

>> What's the status of the gzprintf() buffer-overrun bug?  Is vsnprintf()
>> now turned on by default on platforms that support it?

> Yes.  And when ./configure is run it will warn you if an insecure 
> version of printf is being used.  It would be nice if someone with a 
> compiler that in fact doesn't have snprint() or vsnprintf() could 
> verify that.  By the way, I also rigged it so that if you don't run 
> ./configure, it will try to use vsnprintf() or snprintf() by default, 
> so if they aren't present it will result in an error if you ever try to 
> link gzprintf().

Exxxxxcellent...  You might want to note that a little more prominently
in the ChangeLog, though, and perhaps modify the comment in zlib.h to
be a bit more precise about what the two different consequences of an
overfull printf are (i.e., no output at all or buffer overrun, depending
on how it was compiled).

Would it be worthwhile adding a capabilities function that returns a long
bit flag with this sort of info encoded in it?  That is, bit 0, if set,
would indicate vsnprintf() support; if not set, a buffer overrun is possi-
ble.  All other bits would be zero now, but in the future they might be
used to indicate the presence of other fixes and/or features.  (Or they
could be used to detect and/or set whether assembler routines are used
for various things, which is already done in libpng and is useful for
testing whether such routines are actually of any benefit on a given
processor.)

Greg