Re: [ft-devel] longjmp issue 1

[suzuki toshiya]

Dear Werner,

Here I drafted the changesets to eliminate the switching of
FT_INVALID_(), by 2 approaches.

A) mps20141210_introduce-OTV_INVALID.patch.xz
GXV_INVALID_XXX or OTV_INVALID_XXX are introduced in gxvalid
and otvalid. FT_INVALID_XXX should not be used directly in
these validators.

# oh, it might be possible to define thin wrappers like
# gx_validator_error() and ot_validator_error() that are
# just calling ft_validator_error() after getting appropriate
# "FT_Validator valid".

B) mps20141210_call-FT_VALID-directly.patch.xz
Set `valid' in the functions (in gxvalid and otvalid) using
FT_INVALID_XXX.

Which approach is easier to understand?

Regards,
mpsuzuki

Werner LEMBERG wrote:
>> Just I've committed the patch (I removed FT_VALIDATOR() cast,
>> because I think it's useful for the developer to find passing an
>> invalid pointer).
>>
>> Also I committed 2 changesets renaming "valid" in gxvalid and
>> otvalid if their types are not FT_Validator.
> 
> Thanks!
> 
> 
>     Werner

mps20141210_introduce-OTV_INVALID.patch.xz
Description: Binary data

mps20141210_call-FT_VALID-directly.patch.xz
Description: Binary data