[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <985bbceb3ee046bbbee6199efcf7c90c@AcuMS.aculab.com>
Date: Tue, 12 Oct 2021 08:04:58 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Heiko Carstens' <hca@...ux.ibm.com>
CC: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>
Subject: RE: [PATCH v1 1/1] s390: Use string_upper() instead of open coded
variant
From: Heiko Carstens
> Sent: 11 October 2021 11:10
>
> On Mon, Oct 11, 2021 at 08:21:15AM +0000, David Laight wrote:
> > ...
> > > > + * This snprintf() call does two things:
> > > > + * - makes a NUL-terminated copy of the input string
> > > > + * - pads it with spaces
> > > > + */
> > > > + snprintf(tmp, sizeof(tmp), "%s ", name);
> > >
> > > I can't say I like code where I have to count spaces in order to
> > > verify if the code is actually correct.
> >
> > What it wrong with "%-8.8s" ?
>
> There's nothing wrong with it, except lack of imagination on my side ;)
> Andy, care to to send a separate patch just for extmem.c?
Are any of the snprintf() versions actually correct at all?
The implication of the comment is that the input string might
not be NUL terminated - in which case it shouldn't be passed
to snprintf().
I don't think you can assume that the format processing doesn't
do a strlen() of any %s argument - even if a maximum field
width is given.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists