search

liam-middlebrook / yaml-cpp

Automatically exported from code.google.com/p/yaml-cpp
MIT License
0 stars 0 forks source link

uint8_t gets parsed a char then cast to a uint8_t #201

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
rhs.initialTestingInput=node["initialTestingInput"].as<uint8_t>();

if my yaml file has the key initialTestingInput assigned to say 1, then 
initialTestingInput in my structure will have the value 49 ('0' + 1)

Not clear this is the desired behavior. But also not clear how to handle this 
properly since uint8_t is typedefed as a char...

For the moment I am avoiding uint8_t ...

Original issue reported on code.google.com by zouhair....@gmail.com on 19 Apr 2013 at 6:55

GoogleCodeExporter commented 9 years ago 
I think uint8_t falls under extremely vague territory because of C/C++'s lack 
of distinguished between character and integer types.  There is enough type 
information to handle uint8_t correctly but I think you should be reading it as 
an int and casting it to a uint8_t outside the conversion.  Perhaps uint8_t 
shouldn't be supported.  Conversely maybe support for char as is should be cut 
such that only strings are supported to allow int8/uint8 to work just like any 
other integer.

Original comment by nev...@gmail.com on 21 Apr 2013 at 10:08

GoogleCodeExporter commented 9 years ago 
My solution so far is to just not support int8/uint8 to avoid confusion.

Original comment by zouhair....@gmail.com on 29 Apr 2013 at 4:53

GoogleCodeExporter commented 9 years ago 
Yeah, this is confusing. @nevion, I see both sides of what you're arguing :)

I'll leave this open for now, but probably won't do anything.

Original comment by jbe...@gmail.com on 3 May 2013 at 1:14

GoogleCodeExporter commented 9 years ago 
Issue 251 has been merged into this issue.

Original comment by jbe...@gmail.com on 24 Jan 2015 at 9:21

GoogleCodeExporter commented 9 years ago 
I started looking into this more, and it looks like boost::lexical_cast has the 
same issue - so much so that they even have a FAQ listed:

http://www.boost.org/doc/libs/1_40_0/libs/conversion/lexical_cast.htm#faq

Q: Why does lexical_cast<int8_t>("127") throw bad_lexical_cast? 
A: The type int8_t is a typedef to char or signed char. Lexical conversion to 
these types is simply reading a byte from source but since the source has more 
than one byte, the exception is thrown.

Please use other integer types such as int or short int. If bounds checking is 
important, you can also call numeric_cast:

numeric_cast<int8_t>(lexical_cast<int>("127"));
Q: What does lexical_cast<std::string> of an int8_t or uint8_t not do what I 
expect? 
A: As above, note that int8_t and uint8_t are actually chars and are formatted 
as such. To avoid this, cast to an integer type first:

lexical_cast<std::string>(static_cast<int>(n));

Therefore, I've decided to officially follow their lead and preserve the 
current behavior.

Original comment by jbe...@gmail.com on 24 Jan 2015 at 9:22