[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Lots of new warnings with gcc-7.1.1
[ 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |