httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: snprintf()
Date Tue, 07 Jan 1997 23:29:32 GMT
Other than varags issues (which I think we've already made portable
because of other functions we've got) ... how hard would it be to make an
snprintf that parses the string and uses native sprintf() to do the dirty
work for each piece?

Doing things piece by piece it is pretty easy to limit how much native
sprint will write.

Dean

On Tue, 7 Jan 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > On Tue, 7 Jan 1997, Jim Jagielski wrote:
> > 
> > > Chuck Murcko wrote:
> > > > 
> > > > Marc Slemko liltingly intones:
> > > > > 
> > > > 
> > > > > Note that I think any implementation, especially if it is done
> > > > > before 1.2, needs to have a quick define that can be easily done
> > > > > to make it just a wrapper around sprintf in case the snprintf won't
> > > > > compile on a particular platform.
> > > > > 
> > > > This is a Good Thing.
> > > > 
> > > 
> > > If we provide a snprintf(), it _better_ work and compile. What's
> > > the sense of rewriting code to us snprintf() when our failsafe for
> > > snprintf() is a wrapper around sprintf()? :)
> > 
> > If you are volunteering to test it on every platform that exists, I
> > welcome your input.  But the fact is I don't think we have the resources
> > required to test on every single platform that apache runs on before a
> > release, no matter how early in the beta cycle this went in.  We can
> > probably cover the platforms that somthing like 90% of the users use, but
> > we need to be prepared for the case that it won't compile on some
> > platform.  In that case, the ability to make it simply use a wrapper
> > around sprintf means that Apache still works on that platform as well as
> > it would have without any snprintf patches. 
> 
> 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...
> 
> 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...
> 
> 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...
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>      jim@jaguNET.com           |       http://www.jaguNET.com/
>                   "Not the Craw... the CRAW!"
> 


Mime
View raw message