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 report
Date Mon, 13 Jan 1997 07:59:48 GMT
On Sun, 12 Jan 1997 sameer@c2.net wrote:

> 
> I'm hoping that
> the mynegdouble errors are easily fixed....
> 
> Mynegdouble errors are where the only error was this:
> 
> < mynegdouble = -0.000000
> ---
> > mynegdouble = 0.000000

Those aren't really an error.  If I say foo=-0, should the system keep the
'-' in there or should it think "you moron, there is only one 0"?  There
is no reason a system needs to have two representations for 0.  If there
is only one 0, the system can store a number between -32768 and 32767 in a
signed 16-bit integer; if there is a +0 and a -0, it can only do from
-32767 to 32767.  Integer implementation is in signed two's complement
(which implies only one 0) in every remotely popular system that I can
think of today, but floating point varies a bit more. 

Note that the mynegdouble is being printed by the vendor sprintf, so we
couldn't fix it even if we tried.  <g>


> 	If so then the only problem I've found is on the alpha. I
> suspect a 64-bit-compatibility problem in the code somewhere...
> I mailed the full diffs for the failures to Marc.

Sigh.  

> OSF1 kiwi.cs.berkeley.edu V3.2 214 alpha
> ap_snprintf.c: In function `conv_fp':
> ap_snprintf.c:374: warning: type mismatch in implicit declaration for built-in function
`strlen'
> 	fails with or without cvt

> Linux catlow 2.0.25 #1 Thu Nov 14 15:32:14 PST 1996 alpha
> ap_snprintf.c: In function `conv_fp':
> ap_snprintf.c:374: warning: type mismatch in implicit declaration for built-in function
`strlen'
> ap_snprintf.c: In function `__format_converter':
> ap_snprintf.c:543: warning: implicit declaration of function `isascii'
> 	w/o cvt, fails
> 	w/ cvt, fails

These do need to be figured out.

> HP-UX hpserv A.09.07 A 9000/712 2008449081 two-user license
> 	w/o cvt, works
> 	w/ cvt, compiler error
> ap_snprintf.c:108: conflicting types for `ap_ecvt'
> /usr/local/lib/gcc-lib/hppa1.1-hp-hpux/2.6.0/include/stdlib.h:245: previous declaration
of `ap_ecvt'
> ap_snprintf.c:114: conflicting types for `ap_fcvt'
> /usr/local/lib/gcc-lib/hppa1.1-hp-hpux/2.6.0/include/stdlib.h:243: previous declaration
of `ap_fcvt'
> ap_snprintf.c:125: conflicting types for `ap_gcvt'
> /usr/local/lib/gcc-lib/hppa1.1-hp-hpux/2.6.0/include/stdlib.h:244: previous declaration
of `ap_gcvt'
> *** Error code 1

...and HPUX can, of course, be fixed easily as Alexei mentioned.

Overall, so far it seems to be working pretty well.  My tests are far from
exhaustive, but at least it compiles and exhibits consistent behavior on
most platforms.  

If you look at my test.c, you will note lines commented out because
ap_snprintf doesn't properly and/or at all support them.  For example, %p
is broken, IMHO (outputs deadbeef instead of 0xdeadbeef) and it doesn't
handle shorts (eg. %hd) or quads (eg. %qd) and it seems to truncate when
it reaches the end of the buffer as you would expect a function dealing
with strings to, not as you would expect one dealing with numbers to (not
that that is bad).

When I get Sameer's output from the Alpha stuff I'll see if I can figure
out what is going on there, although I don't have access to a 64-bit
machine for testing.


Mime
View raw message