httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: snprintf()
Date Tue, 07 Jan 1997 20:32:03 GMT
On Tue, 7 Jan 1997, Jim Jagielski wrote:

> Feh... No way. If we decide to use snprintf() then we provide the
> best one we can. If it doesn't compile on someone's OS, well, then
> that's BAD news and we can point them to another simpler one, like
> the one in sendmail. But pretending to provide snprintf() by wrapping
> sprintf() is wrong wrong wrong.
> 
> Right now Apache requires regex and we provide one. We should do the
> same with snprintf(). But we certainly don't provide some half-assed
> non-working regex implementation that doesn't work but does compile.
> 
> If the holes are big enough to force us to snprintf(), then we better
> do it right...

I'm all for doing it right and am not trying to advocate just throwing
something in on the premise that if it doesn't work "oh well".  However,
we are in a bad situation here.  This has come up very late in the beta
cycle.  Most of the platform specific problems that I have seen when
something is added do not result in it compiling and not working, but
result in it not compiling at all.

Here we have a chance to make a fix while still being certain that it will
not break compiles just because our snprintf won't compile.  

> Geez... I'm guessing it would have been your opinion that we not include
> regex unless we were able to test it on every OS out there? Or maybe
> we shouldn't release Apache at _all_ unless we can personally test it
> ourselves on every possible OS...

If the regex library had come in late in the beta cycle and it was a
trivial change to allow apache to work without it, as it had before, then
I would say we should allow for that.

> 
> A very strong -1 on any release that includes such a brain-dead wrapper.
> We do the best we can on providing a solid, "portable" snprintf() and
> leave it at that. We do NOT sanction a simple wrapper, although there's
> nothing against some porter doing it themselves for some weird OS.
> 
> Berkeley DB does that sort of thing, and I think it's nasty there too...

I think that a backup snprintf wrapper which just calls sprintf is a good
thing for 1.2, but should certainly be taken out for the release after
1.2.

The alternative is to expect to need to release a 1.2.1 to fix compile
problems with snprintf (I think that one or more maint. releases in the
1.2 line will be needed anyway).

I guess another beta could be released with the snprintf stuff w/o a
wrapper that calls sprintf if necessary; if we see no or very few
problems, go with it.  If we see much in the way of problems, then we may
need to do something (ie. more testing, adding a last-resort wrapper, or
backing out the snprintf changes). 



Mime
View raw message