Re: Problem report #13 FALSE

[Jason Rumney]

Kenichi Handa <address@hidden> writes:

>> Function: encode_coding_string
>> Description: Variable "(coding)->cmp_data" tracked as NULL was passed to a 
>> function that dereferences it.
>
> I see no bug here.   A member of (coding)->cmp_data is
> accessed only after checking (coding)->cmp_data is not NULL.
>
>> Event var_compare_op: Added "(coding)->cmp_data" due to comparison 
>> "(coding)->cmp_data == 0"
>> Also see events: [var_deref_model]
>> At conditional (1): "(coding)->cmp_data == 0" taking true path
>
>> 6435           if (coding->type != coding_type_ccl
>> 6436               && (! coding->cmp_data || coding->cmp_data->used == 0))
>> 6437             {
>
> Does the checker require it to be writen as below?
>
>> 6436               && (coding->cmp_data ? coding->cmp_data->used == 0 : 1))

I don't think so, as that is not the line it is complaining
about. Rather the line:

6454          result = encode_coding (coding, SDATA (str) + from + consumed,
6455                                  buf.data + produced, to_byte - from - 
consumed,
6456                                  buf.size - produced);

So the question is,
1. Do we reach that line when coding->cmp_data is NULL?
2. Does coding->cmp_data really get dereferenced inside encode_coding
   in the case where it is NULL?

Judging by your previous responses to coding related problem reports,
there is probably some other condition that always prevents both of
these, but I don't understand enough about the coding structure to
tell myself.