Re: [PATCH v3] tools/libs/stat: fix broken build

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.10.2020 08:51, Jürgen Groß wrote:
> On 02.10.20 08:20, Jan Beulich wrote:
>> On 02.10.2020 06:50, Jürgen Groß wrote:
>>> On 01.10.20 18:38, Bertrand Marquis wrote:
>>>> Hi Juergen,
>>>>
>>>>> On 14 Sep 2020, at 11:58, Bertrand Marquis <bertrand.marquis@xxxxxxx> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@xxxxxxxx> wrote:
>>>>>>
>>>>>> Making getBridge() static triggered a build error with some gcc versions:
>>>>>>
>>>>>> error: 'strncpy' output may be truncated copying 15 bytes from a string 
>>>>>> of
>>>>>> length 255 [-Werror=stringop-truncation]
>>>>>>
>>>>>> Fix that by using a buffer with 256 bytes instead.
>>>>>>
>>>>>> Fixes: 6d0ec053907794 ("tools: split libxenstat into new tools/libs/stat 
>>>>>> directory")
>>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>>>
>>>> Sorry i have to come back on this one.
>>>>
>>>> I still see an error compiling with Yocto on this one:
>>>> |     inlined from 'xenstat_collect_networks' at xenstat_linux.c:306:2:
>>>> | xenstat_linux.c:81:6: error: 'strncpy' output may be truncated copying 
>>>> 255 bytes from a string of length 255 [-Werror=stringop-truncation]
>>>> |    81 |      strncpy(result, de->d_name, resultLen);
>>>> |       |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> To solve it, I need to define devBridge[257] as devNoBrideg.
>>>
>>> IMHO this is a real compiler error.
>>>
>>> de->d_name is an array of 256 bytes, so doing strncpy() from that to
>>> another array of 256 bytes with a length of 256 won't truncate anything.
>>
>> That's a matter of how you look at it, I think: If the original array
>> doesn't hold a nul-terminated string, the destination array won't
>> either, yet the common goal of strncpy() is to yield a properly nul-
>> terminated string. IOW the warning may be since the standard even has
>> a specific foot note to point out this possible pitfall.
> 
> If the source doesn't hold a nul-terminated string there will still be
> 256 bytes copied, so there is no truncation done during strncpy().
> 
> In fact there is no way to use strncpy() in a safe way on a fixed sized
> source array with the above semantics: either the target is larger than
> the source and length is at least sizeof(source) + 1, resulting in a
> possible read beyond the end of source, or the target is the same length
> leading to the error.

I agree with all of what you say, but I can also see why said foot note
alone may have motivated the emission of the warning.

Jan