* [PATCH] rangeset: no need to use snprintf()
@ 2021-04-06 8:50 Jan Beulich
2021-04-06 13:44 ` Julien Grall
0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2021-04-06 8:50 UTC (permalink / raw)
To: xen-devel
Cc: Andrew Cooper, George Dunlap, Ian Jackson, Julien Grall,
Stefano Stabellini, Wei Liu
As of the conversion to safe_strcpy() years ago there has been no need
anymore to use snprintf() to prevent storing a not-nul-terminated string.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -436,14 +436,7 @@ struct rangeset *rangeset_new(
BUG_ON(flags & ~RANGESETF_prettyprint_hex);
r->flags = flags;
- if ( name != NULL )
- {
- safe_strcpy(r->name, name);
- }
- else
- {
- snprintf(r->name, sizeof(r->name), "(no name)");
- }
+ safe_strcpy(r->name, name ?: "(no name)");
if ( (r->domain = d) != NULL )
{
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] rangeset: no need to use snprintf()
2021-04-06 8:50 [PATCH] rangeset: no need to use snprintf() Jan Beulich
@ 2021-04-06 13:44 ` Julien Grall
2021-04-06 13:56 ` Jan Beulich
0 siblings, 1 reply; 3+ messages in thread
From: Julien Grall @ 2021-04-06 13:44 UTC (permalink / raw)
To: Jan Beulich, xen-devel
Cc: Andrew Cooper, George Dunlap, Ian Jackson, Stefano Stabellini, Wei Liu
Hi Jan,
On 06/04/2021 09:50, Jan Beulich wrote:
> As of the conversion to safe_strcpy() years ago there has been no need
> anymore to use snprintf() to prevent storing a not-nul-terminated string.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
>
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -436,14 +436,7 @@ struct rangeset *rangeset_new(
> BUG_ON(flags & ~RANGESETF_prettyprint_hex);
> r->flags = flags;
>
> - if ( name != NULL )
> - {
> - safe_strcpy(r->name, name);
> - }
> - else
> - {
> - snprintf(r->name, sizeof(r->name), "(no name)");
> - }
> + safe_strcpy(r->name, name ?: "(no name)");
I realize the current code is not checking the return, but I wonder we
should rather than silently truncating the string.
This is not a new issue, so it can dealt separately if we decide to
check the return.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] rangeset: no need to use snprintf()
2021-04-06 13:44 ` Julien Grall
@ 2021-04-06 13:56 ` Jan Beulich
0 siblings, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2021-04-06 13:56 UTC (permalink / raw)
To: Julien Grall
Cc: Andrew Cooper, George Dunlap, Ian Jackson, Stefano Stabellini,
Wei Liu, xen-devel
On 06.04.2021 15:44, Julien Grall wrote:
> On 06/04/2021 09:50, Jan Beulich wrote:
>> As of the conversion to safe_strcpy() years ago there has been no need
>> anymore to use snprintf() to prevent storing a not-nul-terminated string.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Julien Grall <jgrall@amazon.com>
Thanks.
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -436,14 +436,7 @@ struct rangeset *rangeset_new(
>> BUG_ON(flags & ~RANGESETF_prettyprint_hex);
>> r->flags = flags;
>>
>> - if ( name != NULL )
>> - {
>> - safe_strcpy(r->name, name);
>> - }
>> - else
>> - {
>> - snprintf(r->name, sizeof(r->name), "(no name)");
>> - }
>> + safe_strcpy(r->name, name ?: "(no name)");
>
> I realize the current code is not checking the return, but I wonder we
> should rather than silently truncating the string.
The name field is used only for display purposes, so I guess truncation
wouldn't really be a problem here.
Jan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-04-06 13:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-06 8:50 [PATCH] rangeset: no need to use snprintf() Jan Beulich
2021-04-06 13:44 ` Julien Grall
2021-04-06 13:56 ` Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).