snprintf report

[sa...@c2.net]

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

	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.

FreeBSD laptop.c2.net 2.2-961014-SNAP FreeBSD 2.2-961014-SNAP #0: Sat Nov  9 15:31:30 PST 1996     sameer@laptop.c2.net:/usr/src/sys/compile/LAPNOCRD  i386
works, needs cvt

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

SCO_SV beta 3.2 2 i386
	w/o cvt: failes
	w/cvt: mynegdouble

SunOS cdc6 5.5 Generic_103094-03 i86pc i386 i86pc
ap_snprintf.c: In function `__format_converter':
ap_snprintf.c:543: warning: implicit declaration of function `isascii'
	w/o cvt, fails drastically
	w/cvt: mynegdouble


BSD/386 freeside.fc.net 1.1 0 i386
ap_snprintf.c: In function conv_fp:
ap_snprintf.c:374: warning: implicit declaration of function `strlen'
ap_snprintf.c: In function __format_converter:
ap_snprintf.c:478: warning: unused parameter `fd'
	Needs cvt, works

AIX godzilla 2 3 000020327700 unknown
	w/o cvt, fails miserably
	w/cvt, mynegdouble

Linux www 1.2.13 #3 Sat Dec 9 15:56:31 PST 1995 i486
ap_snprintf.c: In function `__format_converter':
ap_snprintf.c:543: warning: implicit declaration of function `isascii'
	w/o cvt, fails
	w/cvt, mynegdouble


Linux cybernetic 2.0.0 #2 Thu Dec 5 01:14:40 PST 1996 i486
ap_snprintf.c: In function `__format_converter':
ap_snprintf.c:543: warning: implicit declaration of function `isascii'
	w/ or w/o cvt, mynegdouble failure

UNIX_SV cyber2 4.2MP 2.03 i386 x86at
	w/o cvt, fails
	w/cvt, mynegdouble

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

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

ULTRIX ucsee.EECS.Berkeley.EDU 4.4 0 RISC
	w/o cvt, fails
	w/cvt, works

Re: snprintf report

[Marc Slemko <ma...@znep.com>]

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.