On 06/06/12 18:49, Laszlo Ersek wrote:
> 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.
Suppose the v->type_int() call fails and stores a parse error (and that
correspondingly it doesn't modify "value").
Suppose the subsequent range check fails too. In this case the current
code leaks the first Error object.
I didn't try to fix this here because my series starts with a patch from
Paolo that fixes this leak: once an error is pending, further errors are
thrown away (= not formatted / released). With that fix in place, it
doesn't matter if we enter the (value < 0) branch or not: as long as
type_int keeps error setting and value changing mutually exclusive,
we'll keep the first (= type_int) error and keep the value of *obj too.
Laszlo
