From: Egon A. <po...@ta...> - 2005-01-31 11:05:39
|
Hi, I've experienced a strange behaviour of strtold() when the string is "1e". I would have expected that the endptr was pointing at the second char of the above string i.e. the 'e', but apparently it accepts the 'e' as a part of the convertable string and the result is 1.0 Is this a bug or have I misunderstood the behaviour of strtold()? (On my Linux-platform, it works as I expect.) I'm using the pre-built MinGW-3.2.0-rc-1.exe Best regards Egon Andersen |
From: Greg C. <chi...@co...> - 2005-01-31 13:30:42
|
On 2005-01-31 06:05 AM, Egon Andersen wrote: > > I've experienced a strange behaviour of strtold() when the string is "1e". > I would have expected that the endptr was pointing at the second char of > the above string i.e. the 'e', but apparently it accepts the 'e' as a > part of the convertable string and the result is 1.0 As I read C99 6.4.4.2, if an exponent-part is given, then it must contain a digit-sequence. > Is this a bug or have I misunderstood the behaviour of strtold()? > (On my Linux-platform, it works as I expect.) It sounds like a defect of the msvc runtime library. |
From: Egon A. <po...@ta...> - 2005-01-31 14:00:57
|
Greg Chicares wrote: > On 2005-01-31 06:05 AM, Egon Andersen wrote: > >> >> I've experienced a strange behaviour of strtold() when the string is >> "1e". >> I would have expected that the endptr was pointing at the second char >> of the above string i.e. the 'e', but apparently it accepts the 'e' as >> a part of the convertable string and the result is 1.0 > > > As I read C99 6.4.4.2, if an exponent-part is given, then > it must contain a digit-sequence. > >> Is this a bug or have I misunderstood the behaviour of strtold()? >> (On my Linux-platform, it works as I expect.) > > > It sounds like a defect of the msvc runtime library. > I don't think strtold() is in the msvc runtime library, but is in the MinGW extension. Best regards Egon Andersen |
From: Danny S. <dan...@cl...> - 2005-01-31 20:10:59
|
Egon Andersen wrote: > Hi, > > I've experienced a strange behaviour of strtold() when the string is "1e". > I would have expected that the endptr was pointing at the second char of > the above string i.e. the 'e', but apparently it accepts the 'e' as a > part of the convertable string and the result is 1.0 > > Is this a bug or have I misunderstood the behaviour of strtold()? > (On my Linux-platform, it works as I expect.) > I believe it is a bug. Please file as a bug at the SF bug tracker https://sourceforge.net/tracker/?func=add&group_id=2435&atid=102435 so it won't be lost. I've worked up a quick hack to fix, but really needs a better fix. Danny > Best regards > Egon Andersen > > |
From: Greg C. <chi...@co...> - 2005-01-31 20:58:35
|
On 2005-01-31 15:09 PM, Danny Smith wrote: > Egon Andersen wrote: > >>I've experienced a strange behaviour of strtold() when the string is "1e". >>I would have expected that the endptr was pointing at the second char of >>the above string i.e. the 'e', but apparently it accepts the 'e' as a >>part of the convertable string and the result is 1.0 >> >>Is this a bug or have I misunderstood the behaviour of strtold()? >>(On my Linux-platform, it works as I expect.) > > I believe it is a bug. Please file as a bug at the SF bug tracker > https://sourceforge.net/tracker/?func=add&group_id=2435&atid=102435 > so it won't be lost. > > I've worked up a quick hack to fix, but really needs a better fix. Danny, do you mind sharing a prerelease of your quick hack--here, in the sf.net tracker, or by email if you prefer? I've written a numeric-conversion library that uses strtoX() and snprintf(), and I've got lots of unit tests already. (I'll add Egon's test, too.) |
From: Egon A. <po...@ta...> - 2005-01-31 22:02:04
|
Greg Chicares wrote: > On 2005-01-31 15:09 PM, Danny Smith wrote: > >> Egon Andersen wrote: >> >>> I've experienced a strange behaviour of strtold() when the string is >>> "1e". >>> I would have expected that the endptr was pointing at the second char of >>> the above string i.e. the 'e', but apparently it accepts the 'e' as a >>> part of the convertable string and the result is 1.0 >>> >>> Is this a bug or have I misunderstood the behaviour of strtold()? >>> (On my Linux-platform, it works as I expect.) >> >> >> I believe it is a bug. Please file as a bug at the SF bug tracker >> https://sourceforge.net/tracker/?func=add&group_id=2435&atid=102435 >> so it won't be lost. >> >> I've worked up a quick hack to fix, but really needs a better fix. > > > Danny, do you mind sharing a prerelease of your quick hack--here, > in the sf.net tracker, or by email if you prefer? I've written a > numeric-conversion library that uses strtoX() and snprintf(), and > I've got lots of unit tests already. (I'll add Egon's test, too.) > Just for the fun, try to snprintf a double with 2 decimals e.g. ".2f" and let the value be infinity. I get as result something like "1.#J" I think it is time to make a proper implementation of snprintf() not based on M$ Best regards Egon Andersen |
From: Greg C. <chi...@co...> - 2005-02-01 06:03:46
|
On 2005-01-31 17:01 PM, Egon Andersen wrote: > > Just for the fun, try to snprintf a double with 2 decimals e.g. ".2f" > and let the value be infinity. > I get as result something like "1.#J" > I think it is time to make a proper implementation of snprintf() not > based on M$ Other snprintf problems: char buf[100] = "zzzzzzzzz"; std::cout << snprintf(buf, 0, "%4d", 1234) << '\n'; // Should equal 4. std::cout << snprintf(buf, 3, "%4d", 1234) << '\n'; // Should equal 4. std::cout << std::string(buf, 9) << '\n'; // Should be "12\0zzzzzz\0". snprintf(buf, 4, "%4d", 1234); std::cout << std::string(buf, 9) << '\n'; // Should be "123\0zzzzz\0". With the latest release, I get -1 -1 123zzzzzz 1234zzzzz I think it's always been that way. MinGW's sprintf() calls _vsnprintf(), which is known to be defective: http://www.gotw.ca/publications/mill19.htm "In particular, under one major implementation, if the output fills or would overflow the buffer then the buffer is not zero-terminated." |