Re: [platform-testers] texinfo-6.6.90 pretest

[Hans-Bernhard Bröker]

Am 20.08.2019 um 04:40 schrieb Eli Zaretskii:
>> From: Hans-Bernhard Bröker <address@hidden>

>> *) The warning is not entirely unjustified, because the above code is,
>> at the least, somewhat misleading.  The actual number of characters this
>> will add to the output is not 2, as it appears to say right there in the
>> argument list, but 3 (because strncat insists on writing a closing '\0').
> 
> There's nothing wrong with this code: the documentation of strncat
> explicitly says that it will add a null terminator in addition to the
> N characters copied.  This isn't memcpy.

I'm aware of that.  But strncat only adds its own terminating NUL by
itself if the given length parameter was too small to cover the
terminating NUL of the source string.  In that sense, this is a
truncated operation, and might warrant -Wstringop-trunctation, and it is
indeed very close to one of the examples documented for that warning.

Also, those warnings do go away if the length arguments are increased by
one, which is what tricked me into believing this was a mislabelled
-truncation warning in the first place.

And the one in line 1634 changes from "-overflow" to "-truncation" if
-Wstringop-truncation is enabled... (GCC 9 on MSYS2)

>> *) IMHO there must be something wrong with that GCC: the text of the
>> warning mismatches the indicated -W option.  This warning is
>> -Wstringop-truncation, not -Wstringop-overflow
> 
> I suggest to read about these warnings.  

I did. But I found nothing in the GCC documentation saying anything
about warnings in the case that the length argument was based solely on
the source.  In fact, the documentation of this warning does not even
_mention_ the source argument.  The only warning that claims to check
that is -Wstringop-truncate.

> Then you will understand why
> GCC wines about the source length: that's exactly what it wants to
> prevent, this pattern of use where the length argument is taken from
> the source instead of from the destination.

If that's exactly what they intend to do, then they IMHO failed rather
completely at explaining (that aspect of) that intent in the one place
where they should have: "info gcc invoc warn".

I'm aware these strncat() calls in their current shape are not one iota
better than plain old strcat() ones would have been, and that may
warrant a warning.  But the warning, as-is, is way more confusing than
helpful.  The message text just states an obvious fact, and points to
documentation that doesn't explain at all how that fact relates to the
warning being issued.

> The problem is that to satisfy GCC, the code needs to keep track of
> the amount of space left in the destination.

I'd extend that to say that the code needs to do that anyway, regardless
of GCC warnings.  If the use of strncat() over strcat() is to have any
sense at all, that is.