km@emory.uucp (Ken Mandelberg) (01/06/89)
I consider this a bug:
The printf on A/UX will core dump with a floating point
exception on extreme data. For example:
printf("%g\n", 0x7fffffff);
will core dump on A/UX. On our BSD and other USG systems, this
prints "NaN", or some appropriate value (depending on the type
of internal floating point format).
I submit this to this group, since I don't know of another way to
submit A/UX bug reports to Apple.
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {decvax,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963debra@alice.UUCP (Paul De Bra) (01/07/89)
In article <3568@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: }I consider this a bug: } }The printf on A/UX will core dump with a floating point }exception on extreme data. For example: } } printf("%g\n", 0x7fffffff); } }will core dump on A/UX. On our BSD and other USG systems, this }prints "NaN", or some appropriate value (depending on the type }of internal floating point format). I don't consider this a bug. %g expects a double, i.e. 64 bits and you only give it an int, i.e. 32 bits. But maybe you have other examples... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
km@emory.uucp (Ken Mandelberg) (01/07/89)
In article <8686@alice.UUCP> debra@alice.UUCP () writes: >In article <3568@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: >}I consider this a bug: >} >}The printf on A/UX will core dump with a floating point >}exception on extreme data. For example: >} >} printf("%g\n", 0x7fffffff); >} >}will core dump on A/UX. On our BSD and other USG systems, this >}prints "NaN", or some appropriate value (depending on the type >}of internal floating point format). > >I don't consider this a bug. %g expects a double, i.e. 64 bits and >you only give it an int, i.e. 32 bits. > >But maybe you have other examples... > >Paul. >-- >------------------------------------------------------ >|debra@research.att.com | uunet!research!debra | >------------------------------------------------------ I tried to submit this as compactly as possible. Note that the core dump was a floating point exception not a bus error, so it does show that printf can't handle some exceptional data. However, here is another version of the test program which gets the same exception on A/UX (and not the other Unix systems): main () { union { int hex[2]; double d; } data; data.hex[0]=0x7fffffff; data.hex[1]=0xffffffff; printf("%g\n", data.d); } -- Ken Mandelberg | km@mathcs.emory.edu PREFERRED Emory University | {decvax,gatech}!emory!km UUCP Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET Atlanta, GA 30322 | Phone: (404) 727-7963
tjt@samedi.tis.llnl.gov (Tim Tessin) (01/10/89)
In article <3568@emory.uucp> km@emory.uucp (Ken Mandelberg) writes: > I consider this a bug: > > The printf on A/UX will core dump with a floating point > exception on extreme data. For example: > > printf("%g\n", 0x7fffffff); > > will core dump on A/UX. On our BSD and other USG systems, this > prints "NaN", or some appropriate value (depending on the type > of internal floating point format). the following: printf("%f\n", 0x7fffffff); fails also. This was a symptom of a probable compiler bug in the accounting software on A/UX. The accounting command for reporting command records, "acctcms" failed to write its own internal records properly causing a 0x7fffffff to be written. When requested to print in human readable form, blamo! The problem was isolated to a reasonably complex 'if' statement on line 217 of acctcms.c. The binary version shipped with A/UX fails, the binary compiled from AT&T Sys V.2 source fails. I rewrote the 'if' statement in two parts to remove complexity, and it worked. This leads me to believe compiler snafu. Tim Tessin - Lawrence Livermore National Laboratory PHONE: (415) 423-4560 ARPA: tjt@tis.llnl.gov UUCP: {ames,lll-crg,lll-lcc,mordor}!lll-tis!tjt