All of lore.kernel.org
 help / color / mirror / Atom feed
* Lots of new warnings with gcc-7.1.1
@ 2017-07-11 22:35 ` Linus Torvalds
  0 siblings, 0 replies; 35+ messages in thread
From: Linus Torvalds @ 2017-07-11 22:35 UTC (permalink / raw)
  To: Tejun Heo, Jean Delvare, Guenter Roeck,
	Bartlomiej Zolnierkiewicz, Sathya Prakash, James E.J. Bottomley,
	Greg Kroah-Hartman
  Cc: the arch/x86 maintainers, xen-devel, linux-block,
	Linux Media Mailing List, IDE-ML, linux-fbdev,
	Network Development

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.=
1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.

But a lot of the warnings look reasonable, and at least the warnings
are nice in how they actually explain why the warning is happening.
Example:

  arch/x86/platform/intel-mid/device_libs/platform_max7315.c: In
function =E2=80=98max7315_platform_data=E2=80=99:
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:35:
warning: =E2=80=98%d=E2=80=99 directive writing between 1 and 11 bytes into=
 a region
of size 9 [-Wformat-overflow=3D]
     sprintf(base_pin_name, "max7315_%d_base", nr);
                                     ^~
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26:
note: directive argument in the range [-2147483647, 2147483647]

Yeah, the compiler is technically correct, but we already made sure we
have at most MAX7315_NUM of those adapters, so no, "nr" is really not
going to be a 10-digit number.

So the warning is kind of bogus.

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 =E2=80=98le_max_key_size_read=E2=80=99:
  net/bluetooth/smp.c:3372:29: warning: =E2=80=98snprintf=E2=80=99 output m=
ay be
truncated before the last format character [-Wformat-truncation=3D]
    snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
                               ^~~~~~~
  net/bluetooth/smp.c:3372:2: note: =E2=80=98snprintf=E2=80=99 output betwe=
en 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..

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=3D1" kind of warning.  But let's see how
many of these we can fix, ok?

                  Linus

^ permalink raw reply	[flat|nested] 35+ messages in thread
* Lots of new warnings with gcc-7.1.1
@ 2017-07-11 22:35 Linus Torvalds
  0 siblings, 0 replies; 35+ messages in thread
From: Linus Torvalds @ 2017-07-11 22:35 UTC (permalink / raw)
  To: Tejun Heo, Jean Delvare, Guenter Roeck,
	Bartlomiej Zolnierkiewicz, Sathya Prakash, James E.J. Bottomley,
	Greg Kroah-Hartman
  Cc: linux-fbdev, Network Development, the arch/x86 maintainers,
	linux-block, IDE-ML, xen-devel, Linux Media Mailing List

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.

But a lot of the warnings look reasonable, and at least the warnings
are nice in how they actually explain why the warning is happening.
Example:

  arch/x86/platform/intel-mid/device_libs/platform_max7315.c: In
function ‘max7315_platform_data’:
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:35:
warning: ‘%d’ directive writing between 1 and 11 bytes into a region
of size 9 [-Wformat-overflow=]
     sprintf(base_pin_name, "max7315_%d_base", nr);
                                     ^~
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26:
note: directive argument in the range [-2147483647, 2147483647]

Yeah, the compiler is technically correct, but we already made sure we
have at most MAX7315_NUM of those adapters, so no, "nr" is really not
going to be a 10-digit number.

So the warning is kind of bogus.

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..

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?

                  Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2017-07-15 11:03 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-11 22:35 Lots of new warnings with gcc-7.1.1 Linus Torvalds
2017-07-11 22:35 ` Linus Torvalds
2017-07-11 22:35 ` Linus Torvalds
2017-07-11 23:54 ` Marcel Holtmann
2017-07-11 23:54 ` Marcel Holtmann
2017-07-11 23:54   ` Marcel Holtmann
2017-07-12  3:10 ` Guenter Roeck
2017-07-12  3:10   ` Guenter Roeck
2017-07-12  3:17   ` Linus Torvalds
2017-07-12  3:17     ` Linus Torvalds
2017-07-12  3:41     ` Linus Torvalds
2017-07-12  3:41       ` Linus Torvalds
2017-07-12 13:31       ` Arnd Bergmann
2017-07-12 13:31         ` Arnd Bergmann
2017-07-12 13:31         ` Arnd Bergmann
2017-07-15 11:03         ` Tejun Heo
2017-07-15 11:03         ` Tejun Heo
2017-07-15 11:03           ` Tejun Heo
2017-07-12 13:31       ` Arnd Bergmann
2017-07-12  3:41     ` Linus Torvalds
2017-07-12  3:17   ` Linus Torvalds
2017-07-12  3:10 ` Guenter Roeck
2017-07-12  4:19 ` Jakub Kicinski
2017-07-12  4:19 ` Jakub Kicinski
2017-07-12  4:19   ` Jakub Kicinski
2017-07-12 12:37 ` Mauro Carvalho Chehab
2017-07-12 12:37 ` Mauro Carvalho Chehab
2017-07-12 12:37   ` Mauro Carvalho Chehab
2017-07-12 13:10 ` Greg Kroah-Hartman
2017-07-12 13:10 ` Greg Kroah-Hartman
2017-07-12 13:10   ` Greg Kroah-Hartman
2017-07-12 13:51   ` Arnd Bergmann
2017-07-12 13:51     ` Arnd Bergmann
2017-07-12 13:51   ` Arnd Bergmann
2017-07-11 22:35 Linus Torvalds

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.