On Thu, 2024-02-08 at 10:29 +0000, Lee Jones wrote: > On Thu, 08 Feb 2024, Geert Uytterhoeven wrote: > > > Hi Lee, > > > > Thanks for your patch! > > > > On Thu, Feb 8, 2024 at 9:48 AM Lee Jones <lee@xxxxxxxxxx> wrote: > > > There is a general misunderstanding amongst engineers that > > > {v}snprintf() > > > returns the length of the data *actually* encoded into the > > > destination > > > array. However, as per the C99 standard {v}snprintf() really > > > returns > > > the length of the data that *would have been* written if there > > > were > > > enough space for it. This misunderstanding has led to buffer- > > > overruns > > > in the past. It's generally considered safer to use the > > > {v}scnprintf() > > > variants in their place (or even sprintf() in simple cases). So > > > let's > > > do that. > > > > Confused... The return value is not used at all? > > Future proofing. The idea of the effort is to rid the use entirely. > > - Usage is inside a sysfs handler passing PAGE_SIZE as the size > - s/snprintf/sysfs_emit/ > - Usage is inside a sysfs handler passing a bespoke value as the > size > - s/snprintf/scnprintf/ > - Return value used, but does *not* care about overflow > - s/snprintf/scnprintf/ > - Return value used, caller *does* care about overflow > - s/snprintf/seq_buf/ > - Return value not used > - s/snprintf/scnprintf/ > > This is the final case. To re-ask Geert's question: the last case can't ever lead to a bug or problem, what value does churning the kernel to change it provide? As Finn said, if we want to deprecate it as a future pattern, put it in checkpatch. James