[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C983283A-CB6B-47F5-BBCF-ED878ECB191C@holtmann.org>
Date: Wed, 12 Jul 2017 01:54:40 +0200
From: Marcel Holtmann <marcel@...tmann.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Tejun Heo <tj@...nel.org>, Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Sathya Prakash <sathya.prakash@...adcom.com>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
the arch/x86 maintainers <x86@...nel.org>,
xen-devel <xen-devel@...ts.xenproject.org>,
linux-block <linux-block@...r.kernel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
IDE-ML <linux-ide@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>
Subject: Re: Lots of new warnings with gcc-7.1.1
Hi Linus,
> At the same time, others aren't quite as insane, and in many cases the
> warnings might be easy to just fix.
>
> And some actually look valid, although they might still require odd input:
>
> net/bluetooth/smp.c: In function ‘le_max_key_size_read’:
> net/bluetooth/smp.c:3372:29: warning: ‘snprintf’ output may be
> truncated before the last format character [-Wformat-truncation=]
> snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
> ^~~~~~~
> net/bluetooth/smp.c:3372:2: note: ‘snprintf’ output between 4 and 5
> bytes into a destination of size 4
>
> yeah, "max_key_size" is unsigned char, but if it's larger than 99 it
> really does need 5 bytes for "%2u\n" with the terminating NUL
> character.
>
> Of course, the "%2d" implies that people expect it to be < 100, but at
> the same time it doesn't sound like a bad idea to just make the buffer
> be one byte bigger. So..
the Bluetooth specification defines that the Maximum Encryption Key Size shall be in the range 7 to 16 octets. Which is also reflected in these defines:
#define SMP_MIN_ENC_KEY_SIZE 7
#define SMP_MAX_ENC_KEY_SIZE 16
So it is buf[4] since we know it never gets larger than 16. So even in this case the warning is bogus.
I have no problem in increasing it to buf[5] to shut up the compiler, but that is what I would be doing here. I am not fixing an actual bug.
> Anyway, it would be lovely if some of the more affected developers
> would take a look at gcc-7.1.1 warnings. Right now I get about three
> *thousand* lines of warnings from a "make allmodconfig" build, which
> makes them a bit overwhelming.
>
> I do suspect I'll make "-Wformat-truncation" (as opposed to
> "-Wformat-overflow") be a "V=1" kind of warning. But let's see how
> many of these we can fix, ok?
I had to use the -Wno-format-trunction in a few projects since gcc was completely lost. And since we were using snprintf, I saw no point in trying to please gcc with a larger buffer.
Regards
Marcel
Powered by blists - more mailing lists