All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] tools/libs/stat: fix broken build
@ 2020-09-12 13:08 Juergen Gross
  2020-09-14  9:34 ` Wei Liu
  2020-09-14 10:58 ` Bertrand Marquis
  0 siblings, 2 replies; 14+ messages in thread
From: Juergen Gross @ 2020-09-12 13:08 UTC (permalink / raw)
  To: xen-devel; +Cc: Juergen Gross, Ian Jackson, Wei Liu

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@suse.com>
---
 tools/libs/stat/xenstat_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c
index 793263f2b6..d2ee6fda64 100644
--- a/tools/libs/stat/xenstat_linux.c
+++ b/tools/libs/stat/xenstat_linux.c
@@ -78,7 +78,7 @@ static void getBridge(char *excludeName, char *result, size_t resultLen)
 				sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);
 
 				if (access(tmp, F_OK) == 0) {
-					strncpy(result, de->d_name, resultLen - 1);
+					strncpy(result, de->d_name, resultLen);
 					result[resultLen - 1] = 0;
 				}
 		}
@@ -264,7 +264,7 @@ int xenstat_collect_networks(xenstat_node * node)
 {
 	/* Helper variables for parseNetDevLine() function defined above */
 	int i;
-	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, devNoBridge[17] = { 0 };
+	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[256] = { 0 }, devNoBridge[257] = { 0 };
 	unsigned long long rxBytes, rxPackets, rxErrs, rxDrops, txBytes, txPackets, txErrs, txDrops;
 
 	struct priv_data *priv = get_priv_data(node->handle);
-- 
2.26.2



^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-09-12 13:08 [PATCH v3] tools/libs/stat: fix broken build Juergen Gross
@ 2020-09-14  9:34 ` Wei Liu
  2020-09-14 10:58 ` Bertrand Marquis
  1 sibling, 0 replies; 14+ messages in thread
From: Wei Liu @ 2020-09-14  9:34 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Ian Jackson, Wei Liu

On Sat, Sep 12, 2020 at 03:08:36PM +0200, Juergen Gross 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@suse.com>

Acked-by: Wei Liu <wl@xen.org>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-09-12 13:08 [PATCH v3] tools/libs/stat: fix broken build Juergen Gross
  2020-09-14  9:34 ` Wei Liu
@ 2020-09-14 10:58 ` Bertrand Marquis
  2020-10-01 16:38   ` Bertrand Marquis
  1 sibling, 1 reply; 14+ messages in thread
From: Bertrand Marquis @ 2020-09-14 10:58 UTC (permalink / raw)
  To: Juergen Gross; +Cc: open list:X86, Ian Jackson, Wei Liu



> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

> ---
> tools/libs/stat/xenstat_linux.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c
> index 793263f2b6..d2ee6fda64 100644
> --- a/tools/libs/stat/xenstat_linux.c
> +++ b/tools/libs/stat/xenstat_linux.c
> @@ -78,7 +78,7 @@ static void getBridge(char *excludeName, char *result, size_t resultLen)
> 				sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);
> 
> 				if (access(tmp, F_OK) == 0) {
> -					strncpy(result, de->d_name, resultLen - 1);
> +					strncpy(result, de->d_name, resultLen);
> 					result[resultLen - 1] = 0;
> 				}
> 		}
> @@ -264,7 +264,7 @@ int xenstat_collect_networks(xenstat_node * node)
> {
> 	/* Helper variables for parseNetDevLine() function defined above */
> 	int i;
> -	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, devNoBridge[17] = { 0 };
> +	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[256] = { 0 }, devNoBridge[257] = { 0 };
> 	unsigned long long rxBytes, rxPackets, rxErrs, rxDrops, txBytes, txPackets, txErrs, txDrops;
> 
> 	struct priv_data *priv = get_priv_data(node->handle);
> -- 
> 2.26.2
> 
> 



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-09-14 10:58 ` Bertrand Marquis
@ 2020-10-01 16:38   ` Bertrand Marquis
  2020-10-02  4:50     ` Jürgen Groß
  0 siblings, 1 reply; 14+ messages in thread
From: Bertrand Marquis @ 2020-10-01 16:38 UTC (permalink / raw)
  To: Juergen Gross; +Cc: open list:X86, Ian Jackson, Wei Liu

Hi Juergen,

> On 14 Sep 2020, at 11:58, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
> 
> 
> 
>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

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.

Regards
Bertrand

> 
>> ---
>> tools/libs/stat/xenstat_linux.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c
>> index 793263f2b6..d2ee6fda64 100644
>> --- a/tools/libs/stat/xenstat_linux.c
>> +++ b/tools/libs/stat/xenstat_linux.c
>> @@ -78,7 +78,7 @@ static void getBridge(char *excludeName, char *result, size_t resultLen)
>> 				sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);
>> 
>> 				if (access(tmp, F_OK) == 0) {
>> -					strncpy(result, de->d_name, resultLen - 1);
>> +					strncpy(result, de->d_name, resultLen);
>> 					result[resultLen - 1] = 0;
>> 				}
>> 		}
>> @@ -264,7 +264,7 @@ int xenstat_collect_networks(xenstat_node * node)
>> {
>> 	/* Helper variables for parseNetDevLine() function defined above */
>> 	int i;
>> -	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, devNoBridge[17] = { 0 };
>> +	char line[512] = { 0 }, iface[16] = { 0 }, devBridge[256] = { 0 }, devNoBridge[257] = { 0 };
>> 	unsigned long long rxBytes, rxPackets, rxErrs, rxDrops, txBytes, txPackets, txErrs, txDrops;
>> 
>> 	struct priv_data *priv = get_priv_data(node->handle);
>> -- 
>> 2.26.2
>> 
>> 
> 



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-01 16:38   ` Bertrand Marquis
@ 2020-10-02  4:50     ` Jürgen Groß
  2020-10-02  6:20       ` Jan Beulich
  2020-10-02 11:05       ` Andrew Cooper
  0 siblings, 2 replies; 14+ messages in thread
From: Jürgen Groß @ 2020-10-02  4:50 UTC (permalink / raw)
  To: Bertrand Marquis; +Cc: open list:X86, Ian Jackson, Wei Liu

On 01.10.20 18:38, Bertrand Marquis wrote:
> Hi Juergen,
> 
>> On 14 Sep 2020, at 11:58, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>
>>
>>
>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
> 
> 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.

Making devBridge one byte longer would be dangerous, as this would do
a strncpy with length of 257 from a source with a length of 256 bytes
only.

BTW, I think Andrew? has tested my patch with a recent gcc which threw
the original error without my patch, and it was fine with the patch.
Either your compiler (assuming you are using gcc) has gained that error
or you are missing an update fixing it.


Juergen


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  4:50     ` Jürgen Groß
@ 2020-10-02  6:20       ` Jan Beulich
  2020-10-02  6:51         ` Jürgen Groß
  2020-10-02 11:05       ` Andrew Cooper
  1 sibling, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2020-10-02  6:20 UTC (permalink / raw)
  To: Jürgen Groß
  Cc: Bertrand Marquis, open list:X86, Ian Jackson, Wei Liu

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@arm.com> wrote:
>>>
>>>
>>>
>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>
>> 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.

Jan


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  6:20       ` Jan Beulich
@ 2020-10-02  6:51         ` Jürgen Groß
  2020-10-02  6:59           ` Jan Beulich
  0 siblings, 1 reply; 14+ messages in thread
From: Jürgen Groß @ 2020-10-02  6:51 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Bertrand Marquis, open list:X86, Ian Jackson, Wei Liu

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@arm.com> wrote:
>>>>
>>>>
>>>>
>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>
>>> 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.


Juergen


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  6:51         ` Jürgen Groß
@ 2020-10-02  6:59           ` Jan Beulich
  2020-10-02  7:25             ` Jürgen Groß
  0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2020-10-02  6:59 UTC (permalink / raw)
  To: Jürgen Groß
  Cc: Bertrand Marquis, open list:X86, Ian Jackson, Wei Liu

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@arm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>
>>>> 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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  6:59           ` Jan Beulich
@ 2020-10-02  7:25             ` Jürgen Groß
  2020-10-02 10:12               ` Bertrand Marquis
  0 siblings, 1 reply; 14+ messages in thread
From: Jürgen Groß @ 2020-10-02  7:25 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Bertrand Marquis, open list:X86, Ian Jackson, Wei Liu

On 02.10.20 08:59, Jan Beulich wrote:
> 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@arm.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>
>>>>> 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.

The motivation can be explained, yes, but it is wrong. strncpy() is not
limited to source arrays of unknown length. So this warning is making
strncpy() unusable for fixed sized source strings and -Werror. And that
is nothing a compiler should be allowed to do, hence a compiler bug.


Juergen


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  7:25             ` Jürgen Groß
@ 2020-10-02 10:12               ` Bertrand Marquis
  2020-10-02 10:44                 ` Jürgen Groß
  0 siblings, 1 reply; 14+ messages in thread
From: Bertrand Marquis @ 2020-10-02 10:12 UTC (permalink / raw)
  To: Jürgen Groß; +Cc: Jan Beulich, open list:X86, Ian Jackson, Wei Liu

Hi,

> On 2 Oct 2020, at 08:25, Jürgen Groß <jgross@suse.com> wrote:
> 
> On 02.10.20 08:59, Jan Beulich wrote:
>> 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@arm.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>> 
>>>>>> 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.
> 
> The motivation can be explained, yes, but it is wrong. strncpy() is not
> limited to source arrays of unknown length. So this warning is making
> strncpy() unusable for fixed sized source strings and -Werror. And that
> is nothing a compiler should be allowed to do, hence a compiler bug.

I do agree that in this case the compiler is doing to much.

We could also choose to turn off the warning either using pragma (which
i really do not like) or by adding a cflag for this specific file (but this might
hit us later in other places).

All in all this currently makes Xen master and staging not possible to
compile with Yocto so we need to find a solution as this will also
come in any distribution using a new compiler,

Cheers
Bertrand


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02 10:12               ` Bertrand Marquis
@ 2020-10-02 10:44                 ` Jürgen Groß
  2020-10-02 11:03                   ` Bertrand Marquis
  0 siblings, 1 reply; 14+ messages in thread
From: Jürgen Groß @ 2020-10-02 10:44 UTC (permalink / raw)
  To: Bertrand Marquis; +Cc: Jan Beulich, open list:X86, Ian Jackson, Wei Liu

On 02.10.20 12:12, Bertrand Marquis wrote:
> Hi,
> 
>> On 2 Oct 2020, at 08:25, Jürgen Groß <jgross@suse.com> wrote:
>>
>> On 02.10.20 08:59, Jan Beulich wrote:
>>> 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@arm.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>>>
>>>>>>> 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.
>>
>> The motivation can be explained, yes, but it is wrong. strncpy() is not
>> limited to source arrays of unknown length. So this warning is making
>> strncpy() unusable for fixed sized source strings and -Werror. And that
>> is nothing a compiler should be allowed to do, hence a compiler bug.
> 
> I do agree that in this case the compiler is doing to much.

It is plain wrong here. Rendering a Posix defined function unusable for
a completely legal use case is in no way a matter of taste or of "doing
to much". It is a bug.

> We could also choose to turn off the warning either using pragma (which
> i really do not like) or by adding a cflag for this specific file (but this might
> hit us later in other places).
> 
> All in all this currently makes Xen master and staging not possible to
> compile with Yocto so we need to find a solution as this will also
> come in any distribution using a new compiler,

A variant you didn't mention would be open coding of strncpy() (or
having a related inline function in a common header). This route would
be the one I'd prefer in case the compiler guys insist on the behavior
being fine.

You didn't tell us which compiler is being used and whether it really is
up to date. A workaround might be to set EXTRA_CFLAGS_XEN_TOOLS to
"-Wno-stringop-truncation" for the build.


Juergen



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02 10:44                 ` Jürgen Groß
@ 2020-10-02 11:03                   ` Bertrand Marquis
  2020-10-02 14:07                     ` Bertrand Marquis
  0 siblings, 1 reply; 14+ messages in thread
From: Bertrand Marquis @ 2020-10-02 11:03 UTC (permalink / raw)
  To: Jürgen Groß; +Cc: Jan Beulich, open list:X86, Ian Jackson, Wei Liu



> On 2 Oct 2020, at 11:44, Jürgen Groß <jgross@suse.com> wrote:
> 
> On 02.10.20 12:12, Bertrand Marquis wrote:
>> Hi,
>>> On 2 Oct 2020, at 08:25, Jürgen Groß <jgross@suse.com> wrote:
>>> 
>>> On 02.10.20 08:59, Jan Beulich wrote:
>>>> 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@arm.com> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>>>> 
>>>>>>>> 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.
>>> 
>>> The motivation can be explained, yes, but it is wrong. strncpy() is not
>>> limited to source arrays of unknown length. So this warning is making
>>> strncpy() unusable for fixed sized source strings and -Werror. And that
>>> is nothing a compiler should be allowed to do, hence a compiler bug.
>> I do agree that in this case the compiler is doing to much.
> 
> It is plain wrong here. Rendering a Posix defined function unusable for
> a completely legal use case is in no way a matter of taste or of "doing
> to much". It is a bug.

Agree.

> 
>> We could also choose to turn off the warning either using pragma (which
>> i really do not like) or by adding a cflag for this specific file (but this might
>> hit us later in other places).
>> All in all this currently makes Xen master and staging not possible to
>> compile with Yocto so we need to find a solution as this will also
>> come in any distribution using a new compiler,
> 
> A variant you didn't mention would be open coding of strncpy() (or
> having a related inline function in a common header). This route would
> be the one I'd prefer in case the compiler guys insist on the behavior
> being fine.

True this possible, even though I do not like to modify the code that deeply
for one specific compiler.

> 
> You didn't tell us which compiler is being used and whether it really is
> up to date. A workaround might be to set EXTRA_CFLAGS_XEN_TOOLS to
> "-Wno-stringop-truncation" for the build.

That’s what i meant by “adding a cflag”, as you suggest we could also
make it global (and not limit it to this file).

The compiler I am using is the one from Yocto Gatesgarth (release coming in
october): gcc version 10.2.0 (released in july 2020).

Cheers

Bertrand



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02  4:50     ` Jürgen Groß
  2020-10-02  6:20       ` Jan Beulich
@ 2020-10-02 11:05       ` Andrew Cooper
  1 sibling, 0 replies; 14+ messages in thread
From: Andrew Cooper @ 2020-10-02 11:05 UTC (permalink / raw)
  To: Jürgen Groß, Bertrand Marquis
  Cc: open list:X86, Ian Jackson, Wei Liu

On 02/10/2020 05: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@arm.com> wrote:
>>>
>>>
>>>
>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>
>> 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.
>
> Making devBridge one byte longer would be dangerous, as this would do
> a strncpy with length of 257 from a source with a length of 256 bytes
> only.
>
> BTW, I think Andrew? has tested my patch with a recent gcc which threw
> the original error without my patch, and it was fine with the patch.
> Either your compiler (assuming you are using gcc) has gained that error
> or you are missing an update fixing it.

All I was doing was using the gitlab CI, and reporting the failing tests.

~Andrew


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] tools/libs/stat: fix broken build
  2020-10-02 11:03                   ` Bertrand Marquis
@ 2020-10-02 14:07                     ` Bertrand Marquis
  0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Marquis @ 2020-10-02 14:07 UTC (permalink / raw)
  To: Jürgen Groß; +Cc: Jan Beulich, open list:X86, Ian Jackson, Wei Liu



> On 2 Oct 2020, at 12:03, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
> 
> 
> 
>> On 2 Oct 2020, at 11:44, Jürgen Groß <jgross@suse.com> wrote:
>> 
>> On 02.10.20 12:12, Bertrand Marquis wrote:
>>> Hi,
>>>> On 2 Oct 2020, at 08:25, Jürgen Groß <jgross@suse.com> wrote:
>>>> 
>>>> On 02.10.20 08:59, Jan Beulich wrote:
>>>>> 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@arm.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 12 Sep 2020, at 14:08, Juergen Gross <jgross@suse.com> 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@suse.com>
>>>>>>>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>>>>> 
>>>>>>>>> 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.
>>>> 
>>>> The motivation can be explained, yes, but it is wrong. strncpy() is not
>>>> limited to source arrays of unknown length. So this warning is making
>>>> strncpy() unusable for fixed sized source strings and -Werror. And that
>>>> is nothing a compiler should be allowed to do, hence a compiler bug.
>>> I do agree that in this case the compiler is doing to much.
>> 
>> It is plain wrong here. Rendering a Posix defined function unusable for
>> a completely legal use case is in no way a matter of taste or of "doing
>> to much". It is a bug.
> 
> Agree.
> 
>> 
>>> We could also choose to turn off the warning either using pragma (which
>>> i really do not like) or by adding a cflag for this specific file (but this might
>>> hit us later in other places).
>>> All in all this currently makes Xen master and staging not possible to
>>> compile with Yocto so we need to find a solution as this will also
>>> come in any distribution using a new compiler,
>> 
>> A variant you didn't mention would be open coding of strncpy() (or
>> having a related inline function in a common header). This route would
>> be the one I'd prefer in case the compiler guys insist on the behavior
>> being fine.
> 
> True this possible, even though I do not like to modify the code that deeply
> for one specific compiler.
> 
>> 
>> You didn't tell us which compiler is being used and whether it really is
>> up to date. A workaround might be to set EXTRA_CFLAGS_XEN_TOOLS to
>> "-Wno-stringop-truncation" for the build.
> 
> That’s what i meant by “adding a cflag”, as you suggest we could also
> make it global (and not limit it to this file).
> 
> The compiler I am using is the one from Yocto Gatesgarth (release coming in
> october): gcc version 10.2.0 (released in july 2020).

After some discussion, I will propose a patch to solve the issue using memcpy
instead of strncpy as in this specific case we know that we can truncate the
string.
This will also allow to revert the big buffers in stack.

Cheers
Bertrand


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2020-10-02 14:08 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-12 13:08 [PATCH v3] tools/libs/stat: fix broken build Juergen Gross
2020-09-14  9:34 ` Wei Liu
2020-09-14 10:58 ` Bertrand Marquis
2020-10-01 16:38   ` Bertrand Marquis
2020-10-02  4:50     ` Jürgen Groß
2020-10-02  6:20       ` Jan Beulich
2020-10-02  6:51         ` Jürgen Groß
2020-10-02  6:59           ` Jan Beulich
2020-10-02  7:25             ` Jürgen Groß
2020-10-02 10:12               ` Bertrand Marquis
2020-10-02 10:44                 ` Jürgen Groß
2020-10-02 11:03                   ` Bertrand Marquis
2020-10-02 14:07                     ` Bertrand Marquis
2020-10-02 11:05       ` Andrew Cooper

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.