[boost] Re: lexical_cast again...

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-07-04 17:55:52

On Thu, 4 Jul 2002 20:16:22 +0200, Terje Slettebø
<tslettebo_at_[hidden]> wrote:

>>From: "Stéphane Bronsart" <stephane.bronsart_at_[hidden]>
>
>> A signed long can hold value from -2147483648 to 2147483647
>>
>> signed long l;
>>
>> 1) l=lexical_cast<signed long>("2147483647");      // Ok l = 2147483647
>> 2) l=lexical_cast<signed long>("2147483648");      // False : no exception
>> and l = -2147483648
>> 3) l=lexical_cast<signed long>("2147483650");      // OK exception occurs
>> !!!
>>
>> Why case 2 don't throw exception and case 3 yes ?
>> If lexical_cast throw exption with a value 3 unit greater than the limit,
>> why not with a value 1 greater than the limit ?
>
>This must depend on the implementation of the stream operators for "long".

Yes, I've verified that STLport 4.5.3 has this bug. I'll report it to
Boris. Note that, though

http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#23

makes all the issue quite problematic, I don't think the STLport
behaviour is intentional (Why allowing LONG_MAX + 1 and not LONG_MAX +
2 ?)

[ snip... ]

>> The final solution, for me, is a "specialized" conversion routine/template
>> dedicated to string/integer conversion.
>
>There are already such conversions, in the C library. The rationale for
>lexical_cast is explained in the docs for it. The purpose of lexical_cast is
>to improve these ways, also to make it more general. If all you need is
>string/integer conversion, there's atoi() and scanf().

The atof, atoi, atol (and atoll) functions never check for
overflows/underflows. Indeed it's better to avoid them if you are not
absolutely sure that the resulting value can be represented, because
the invoke *undefined behavior* otherwise. If you care about errors
you can use the strtol, strtoll, strtoul, and strtoull functions. 

> However, these have
>their own issues, particularly scanf(). lexical_cast uses the stream
>operators, which means that it also takes into account the currently set
>locale, something the C functions don't.

Yes :-)

Genny.