On 06/06/12 18:14, Michael Roth wrote:
> On Wed, Jun 06, 2012 at 05:30:03PM +0200, Laszlo Ersek wrote:
>> value < 0
>
> I think this last one will cause problems though, since uint64_t's
> within the valid range for visit_type_uint64() will fail due to being
> interpreted as < 0 when cast to int64_t. With the others we can detect
> these cases since the max unsigned value doesn't exceed the max signed
> value of the intermediate type we're storing to.
The fallback (*v->type_int)() call stores an int64_t, according to its
prototype ("interface contract"). IMHO it shouldn't try to communicate a
mathematical value outside of [INT64_MIN, INT64_MAX]; it should report
an error in this case. If a visitor genuinely wants to parse and store
2^63 for example, it should implement the "type_uint64" interface.
Anyway I've been called "inflexible" before. I can send a v2 if you wish.
Thanks,
Laszlo
