[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6bb054d2-66c9-361c-bae6-c457b20d6870@prevas.dk>
Date: Tue, 2 Aug 2022 11:45:20 +0200
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: David Laight <David.Laight@...LAB.COM>,
'Miguel Ojeda' <ojeda@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jarkko Sakkinen <jarkko@...nel.org>,
Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH v8 02/31] kallsyms: avoid hardcoding buffer size
On 02/08/2022 10.29, David Laight wrote:
> From: Miguel Ojeda
>> Sent: 02 August 2022 02:50
>> - rc = fscanf(in, "%llx %c %499s\n", &addr, &type, name);
>> + rc = fscanf(in, "%llx %c %" _stringify(KSYM_NAME_LEN_BUFFER) "s\n", &addr, &type, name);
>
> Think I'd use "%*s" - simpler.
> Although I normally completely avoid scanf() - too easy to get wrong.
Indeed, and your suggestion is a perfect example: for scanf, * doesn't
mean "there's an int argument specifying the 'precision'", quite the
contrary. man fscanf:
• An optional '*' assignment-suppression character: scanf()
reads input as directed by the conversion specification, but
discards the input. No corresponding pointer argument is re‐
quired, and this specification is not included in the count of
successful assignments returned by scanf().
Rasmus
Powered by blists - more mailing lists