Hi,
On 8/29/20 9:23 PM, Joe Perches wrote:
> While doing an investigation for a possible treewide conversion of
> sysfs output using sprintf/snprintf/scnprintf, I discovered
> several instances of sysfs output without terminating newlines.
>
> It seems likely all of these should have newline terminations
> or have the \n\r termination changed to a single newline.
I think that it could break badly written scripts in rare cases.
>
> Anyone have any objection to patches adding newlines to these
> in their original forms using sprintf/snprintf/scnprintf?
I'm not sure about existing cases, but I think it's a good
checkpatch.pl warning for new patches. It should be
possible to check sysfs_emit() calls.
Thanks,
Denis
On Sat, 2020-08-29 at 23:23 +0300, Denis Efremov wrote:
> Hi,
>
> On 8/29/20 9:23 PM, Joe Perches wrote:
> > While doing an investigation for a possible treewide conversion of
> > sysfs output using sprintf/snprintf/scnprintf, I discovered
> > several instances of sysfs output without terminating newlines.
> >
> > It seems likely all of these should have newline terminations
> > or have the \n\r termination changed to a single newline.
>
> I think that it could break badly written scripts in rare cases.
Maybe.
Is sysfs output a nominally unchangeable api like seq_?
Dunno. seq_ output is extended all the time.
I think whitespace isn't generally considered part of
sscanf type input content awareness.
> > Anyone have any objection to patches adding newlines to these
> > in their original forms using sprintf/snprintf/scnprintf?
>
> I'm not sure about existing cases, but I think it's a good
> checkpatch.pl warning for new patches. It should be
> possible to check sysfs_emit() calls.
Eventually, yes.
cheers, Joe