httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Finish 1.2!
Date Sat, 11 Jan 1997 13:30:26 GMT
Marc Slemko wrote:
> 
> 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...
> 
> 
> 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
> 

Looks like most OSs _don't_ have snprintf()... I would guess the best
solution would be similar to what we do for regex: provide a
version and allow for people to use that one if they need to or
want to. No need to rename it since even if the OS has snprintf,
if Apache is setup to compile it's own, any linker worth it's
salt will use that version instead of the one in libc (or
whereever).

The reason I'm opposed to calling it apache_snprintf() is that it's
not Apache specific nor "enhanced" for Apache (unless we base it
on Ben's *printf() stuff). It's simply snprintf().

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"

Mime
View raw message