This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project. See the libstdc++ home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Joao Cardoso <jcardoso@inescn.pt> writes: | Ulrich Drepper wrote: | > | > Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes: | ... | > > Typically, this will print "Infinity" or "Inf". | > > What happens when a user tries to read back the output? Should we | > > extend the langage so that extracting "Infinity" (or "Inf") be treated | > > as a lexeme that happens to represent numeric_limits<double>::infinity()? | > | > Yes, definitely. This is what the strtod() function in glibc does. | > | > It also has to handle NaNs which can be written as | > | > NAN | > NAN(0x234) | > | | Hi, I have a patch available, but I need some advise here: | | 1-Should NaNs and Infs be generated by the compiler, generating a | warning at library compile time (double f=1./0.;), or should they be | generated ( *f = 0x...)? The library has builtin functions to generate NaNs and Infs. (volatile makes the compiler not to complain). | | In the former case, the compiler warning can be disturbing for the user, | but it generate the numbers in an architecture independent way (VAX, | ix86, m68k, ...), while in the second case I must have the | representation of NaNs and Infs in those architectures -- unless they | are all IEEE/ISO/XXXsomething conforming. It is almost impossible to do speak of NaNs and Infs out of the scope of IEEE 754 or IEC 559 or ISO/IEC 1067. | If the correct approach is the last one, could someone check the | correctness of the following? | | NaN = 0xfff8000000000000 | +Inf = 0x7ff0000000000000 | -Inf = 0xfff0000000000000 I assume you meant endian-free representation. | | 2-If I remember correcty, NaNs can have several internal | representations. I think that any one of them will be just as good as | the others, as "NaN OP number" is always a NaN. Is this correct? NaNs don't compare equal, and I would suggest we report NaNs with mantissa. This is the approach taken in glibc | 3- My parsing recognizes: | | [+-]inf[inity] | [+-]nan | | with any mixing of upper or lower case. | The above construct, nan(0x234) is not recognized. Is it really needed? Yes. -- Gaby