httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Finish 1.2!
Date Sat, 11 Jan 1997 06:37:42 GMT
On Fri, 10 Jan 1997, Jim Jagielski wrote:

> Brian Behlendorf wrote:
> > 
> > On Fri, 10 Jan 1997, Marc Slemko wrote:
> > > > Here's a timetable: 
> > > > 
> > > >   01/14 Release 1.2b5
> > > 
> > > Urp.  If I'm unlucky, it may be a couple of days after that before I can
> > > finsh snprintf patches, have them looked at, and we can sort out a few
> > > details about how they should be compiled in.  If buffer overflow fixes
> > > are going to go in 1.2, they need to be in the next beta.
> > 
> > I consider that to be a priority as well, and worth waiting for.  Biting the
> > bullet: it will need at least a b6 to account for porting issues related to
> > snprintf, I'm guessing.  So back up my timetable by a week?
> > 
> 
> Sounds good to me. If all are agreed I'll place the snprintf()
> "stuff" in util.c wrapped by a HAVE_SNPRINTF. We can then start
> adjusting the values in conf.h for those that require it.

Do we want a HAVE_SNPRINTF or a NO_SNPRINTF?

A choice between making needing a define for outdated silly operating
systems and needing a define for more up to date silly operating systems. 

If it is called snprintf, if we guess wrong about if an OS has snprintf
the compile will break and the person will have to flip the define
themself; if we use apache_snprintf (don't like that name, but that
isn't the issue right now) then it can work on every platform that
our snprintf compiles on, it just won't use the native snprintf if
we don't know about it.  Are there more OSes with snprintf or
without?

I guess a HAVE_SNPRINTF would be more obvious to find the fix when
things broke during compilation...

> 
> For BSD-based systems, they can use a much cleaner version of snprintf()
> which basically uses some hooks in stdio. This may be more trouble

Most BSD based systems that I would be willing to trust this on have
snprintf anyway I think...

> than it's worth however. How about a list of OSs that have snprintf()?
> I can fold that it when I add snprintf() itself.

Of the ones I could test right now...

No snprintf:
	SunOS falun 5.5 Generic_103093-06 sun4m
	SunOS obed-le0 4.1.4 1 sun4m
	AIX gpu5 1 4 000002929000
	IRIX cab101 5.3 11091812 IP22
	HP-UX nyquist B.10.01 A 9000/735 2014046246 two-user license

snprintf:
	FreeBSD alive.ampr.ab.ca 2.1.5-RELEASE FreeBSD 2.1.5-RELEASE #5: Mon Nov 18 21:48:25 MST
1996     marcs@alive.ampr.ab.ca:/usr/home/marcs/FreeBSD/sys/compile/ALIVE  i386
	BSD/OS valis.worldgate.com 2.0.1 BSDI BSD/OS 2.0.1 Kernel #18: Sun Nov 10 19:11:13 MST 1996
marcs@valis.worldgate.com:/misc/marcs/sys/compile/VALIS  i386

I can test to be sure our snprintf compiles on the above before
release, although some of them are very common.  I think it would
be good to try for at least one report of success on each platform
that there is explicit support somewhere for.

Does OS/2 have snprintf?

Others that should have no problems with snprintf:

	OpenBSD
	NetBSD
	Linux



Mime
View raw message