httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: and now back to snprintf (fwd)
Date Thu, 16 Jan 1997 03:41:20 GMT
On Wed, 15 Jan 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > What are you suggesting your wrapper around sprintf() for?  I was under
> > the impression that you were suggesting avoiding portability problems with
> > our snprintf() implementation by simply using a wrapper around sprintf()
> > instead, but looking at what you are saying now perhaps that is a
> > mistaken impression?
> > 
> Sounds like it... I recall awhile ago we were considering a switched
> approach to the snprintf-availability problem. We had:
> 	1. If the OS has snprintf() already, use it
> 	2. If not, then use our ap_snprintf()
> 	3. If for some reason #2 doesn't work, then
> 	    we would provide a USE_SPRINTF_AS_SNPRINTF
> 	    option as a last resort.
> All my comments were about #3... I'm not really comfy with #3
> since it opens us up to notices like "If you compiled Apache
> using their USE_SPRINTF_AS_SNPRINTF option -blah blah blah-" :)
> If we do #3, then it should be the braindead version used in
> DB

Shucks.  Guess need to stop disagreeing then.  I was under the impression
that you were commenting on #2.  

So do:
	- if we know the OS has snprintf use it
	- otherwise use ap_snprintf
	- if it fails, have 'em come crying to us to make them feel
	  better and hopefully fix the problem.

I would like to avoid breaking everything if our ap_snprintf doesn't
compile, but I don't think it is worth wasting much effort on because
it would be a short term thing anyway.  So how about we say bye-bye
entirely to option #3?  The first try at ap_snprintf had pretty good
results WRT compiling and working.

You get any further on the 64-bit stuff?  I am soon going to be to the
point where the patches are done, so if you don't have an idea of
where you are going with that I will start looking harder.

View raw message