John Snow <js...@redhat.com> writes: > On 07/21/2014 03:48 AM, Markus Armbruster wrote: >> >> It certainly could check whether the value fits into uint64_t. >> >> A quick peek at how string-input-visitor.c uses strtoll() makes me >> cringe. >> >> [...] > > What I meant by that was to say that by the time a value was returned > to visit_type_uint64, the value has already been possibly converted > implicitly from a negative value, and we can't tell at this level if > that happened without re-inspecting the string we were passed. At that > point, why not just fix the string parsing mechanics one more layer > down in parse_type_int() -- or by creating another routine primitive; > i.e parse_type_uint. > > As Eric Blake noted elsewhere in the thread, it would be nice to have > the ability to have three behaviors at the lowest level -- signed, > unsigned with wraparound, and unsigned strict. The biggest question in > my mind is how to add the property flag to allow authors to opt-in to > the unsigned with wraparound option, where the unsigned strict option > makes the most sense to me as a default.
Do we have a use case for silently mapping negative numbers to positive ones? > For now I will just fix the error message. We can draft ideas for how > to fix the semantic issues in parsing later. Yes, that makes sense.
