Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

errors in C



It would be a bug in the library not the compiler. Yes, HUGE_VAL should
not cause printf to crash. However, there are values that a double can
be set to that will cause a crash on some system. In IEEE speak, the
system must supply +infinity, -infinity, Quiet NaN and Signalling NaN. A
Signalling NaN will cause a floating point exception. So, while I don't
think that atof() or strtod() would crash (unless an invalid pointer is
passed to them), it is better to test for HUGE_VAL and not try to print
it. 
On Wed, 29 Jan 2003 20:00:31 -0500
Derek Martin <blu at sophic.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, Jan 29, 2003 at 03:46:49PM -0500, Jerry Feldman wrote:
> > Also, I would not print out the value of test. The reason is that in
> > most of the math library, the double return value is set to HUGE_VAL
> > on failure, and errno is set appropriately. If no error is raised,
> > then the functions return the appropriate result and do not change
> > the value of errno.  The atof() function is only a wrapper around
> > the strtod(), and can also return HUGE_VAL. In any case, if test
> > contains an unrepresentable value, it could cause fprintf to crash. 
> 
> Crashing seems unlikely (i.e. impossible), unless there's a bug in the
> compiler, or unless I'm missing something.  If the float variable test
> is set to HUGE_VAL by the C library, then the compiler must
> automatically convert whatever the value of the macro HUGE_VAL is into
> something that will fit into a float.  Even if it doesn't (which I
> don't see how it couldn't), when you print it out via printf, the %f
> format specifier will force the value to be converted to a float.
> Barring a compiler bug, I don't see how this could cause a problem...
> 
> I also note the type of error Doug was testing for: failure to convert
> a non-numeric string into a number.
> 
> > > > error 4
> > > test: 4.000000
> > > error with number: 0
> > > > error rtw
> > > test: 0.000000
> > > error with number: 0
> 
> All of the stuff you added to his code is good for checking the cases
> where the user enters a number that's out of range...  However
> checking for the above can only be done with strtod() or one of its
> brothers, as atof() does not do this kind of error checking; and for
> this, errno does not come into play at all...
> 
> - -- 
> Derek D. Martin
> http://www.pizzashack.org/
> GPG Key ID: 0xDFBEAD02
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE+OHkvHEnASN++rQIRAu20AJ0Xx2hZ77x8U5YQ63fa07yHivcU8ACgkimD
> CaNtXdB7cBmHsL1c8DsFf5w=
> =dOmA
> -----END PGP SIGNATURE-----
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20030129/2fb5d554/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org