[PATCH] improve out-of-bounds checking with GCC 10 attribute access [BZ #25219]

[Martin Sebor]

On 5/4/20 11:34 AM, Martin Sebor wrote:
> On 5/1/20 4:02 PM, DJ Delorie wrote:
>> Martin Sebor <msebor@gmail.com> writes:
>>> Thanks for the careful review!
>>
>> This new version LGTM.
>>
>> Reviewed-by: DJ Delorie <dj@redhat.com>
>>
>> (but IMHO a second set of eyes would be good for this one)

I missed this suggestion.  I'd certainly welcome another pair of eyes
on this.  Just to be clear: unlike _FORTIFY_SOURCE, the effect of
the changes is only to trigger warnings in response to the detected
overflow, not actually cause calls to abort at runtime in those cases.

Martin


>>
>>> Yes, that's wrong.  Good catch!  I completely missed stdio when
>>> testing so I also didn't notice I forgot to add the attribute to
>>> fgets() itself.  I've fixed that in the updated patch.
>>
>> Ok.
>>
>>>> IMHO comment should state that the first argument is index 1.
>>>>
>>>> IMHO should document what happens when size-index is missing.
>>>
>>> I've tweaked the comment a bit.  I hesitate to go into a lot of
>>> detail here and would expect people needing it to read the manual.
>>
>> Right, but there should be just enough info for someone adding a new use
>> of it to know what to do, without requiring the gcc docs.  The new
>> comment is fine.
>>
>>>> __buf[???]
>>>
>>> When size-index is missing at least one byte of the array must be
>>> accessible (or the pointer must be null).  There's no way to specify
>>> a constant size with the current syntax.  In the future I'd like to
>>> try to teach GCC to get it from the argument itself (for ordinary
>>> arrays as well as for VLAs):
>>
>> Makes sense, just didn't know.
>>
>>>> NOTE: does not use the __attr_access macro
>>>
>>> Fixed, thanks.
>>
>> Ok.
>>
> 
> Thanks.  I have committed the latest patch in
> 06febd8c6705c816b2f32ee7aa1f4c0184b05248.
> 
> Martin