1*53924eb5Sriastradh$NetBSD: README.warnings,v 1.5 2023/08/08 11:50:22 riastradh Exp $ 288427844Smrg 388427844SmrgWhat to do about GCC warnings and NetBSD. 488427844Smrg 588427844Smrg 688427844SmrgNew GCC releases always come with a host of new warnings and 788427844Smrgeach new warning can find real bugs, find odd code, or simply 888427844Smrgbe a pain of new useless warnings, or all three and more. 988427844Smrg 1088427844SmrgAs each warning has its own set of issues they each have their 1188427844Smrgown section and it is expected that this document will be 1288427844Smrgmodified for updates to warnings and new warnings. 1388427844Smrg 1488427844Smrg 1588427844Smrg<bsd.own.mk> provides several variables for use in Makefiles: 16c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_FORMAT_TRUNCATION} 17c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_FORMAT_OVERFLOW} 18c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_STRINGOP_OVERFLOW} 19c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_STRINGOP_TRUNCATION} 20c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_CAST_FUNCTION_TYPE} 21c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_IMPLICIT_FALLTHROUGH} 22f937c412Slukem COPTS.foo.c += ${CC_WNO_ADDRESS_OF_PACKED_MEMBER} 23c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_MAYBE_UNINITIALIZED} 24c4b7a9e7Slukem COPTS.foo.c += ${CC_WNO_RETURN_LOCAL_ADDR} 25832d4752Smrg COPTS.foo.c += ${CC_WNO_MISSING_TEMPLATE_KEYWORD} 26832d4752Smrg COPTS.foo.c += ${CC_WNO_STRINGOP_OVERREAD} 27832d4752Smrg COPTS.foo.c += ${CC_WNO_REGISTER} 28832d4752Smrg COPTS.foo.c += ${CC_WNO_ARRAY_BOUNDS} 29832d4752Smrg 30832d4752Smrg 31832d4752Smrgnew GCC 12 warnings: 32832d4752Smrg 33832d4752Smrg -Wno-missing-template-keyword 34832d4752Smrg 35832d4752Smrg This warning trips on older C++ code, and should only be applyed to 3rd 36832d4752Smrg party code. 37832d4752Smrg 38832d4752Smrg bsd.own.mk variable: ${CC_WNO_MISSING_TEMPLATE_KEYWORD} 39832d4752Smrg 40832d4752Smrg -Wno-stringop-overread 41832d4752Smrg 42832d4752Smrg This warning triggers when array bounds appear to be exceeded. There 43832d4752Smrg maybe some bugs related to this warning in GCC 12. 44832d4752Smrg 45832d4752Smrg bsd.own.mk variable: ${CC_WNO_STRINGOP_OVERREAD} 46832d4752Smrg 47832d4752Smrg -Wno-register 48832d4752Smrg 49832d4752Smrg This warning triggers in C++17 mode where 'register' has been removed, 50832d4752Smrg and should only be applied to 3rd party code. 51832d4752Smrg 52832d4752Smrg bsd.own.mk variable: ${CC_WNO_REGISTER} 53832d4752Smrg 54832d4752Smrg -Wno-array-bounds 55832d4752Smrg 56832d4752Smrg This warning triggers with a number of code issues that tend to be real 57832d4752Smrg problem but require careful adjustments to fix properly, when there are 58832d4752Smrg platform related accesses beyond the immediately size and address of 59832d4752Smrg known variables (real bugs to fix), but also may trigger when passing 60832d4752Smrg C arrays vs C pointers to functions, often incorrectly. See 61832d4752Smrg https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110878 62832d4752Smrg 63832d4752Smrg bsd.own.mk variable: ${CC_WNO_ARRAY_BOUNDS} 6488427844Smrg 6588427844Smrg 6688427844Smrgnew GCC 10 warnings: 6788427844Smrg 6888427844Smrg GCC 10 switched the default from "-fcommon" to "-fno-common", 6988427844Smrg which can cause multiply defined symbol issues. Ideally we 7088427844Smrg fix all of these, but "-fcommon" can be used otherwise. 7188427844Smrg 7288427844Smrg -Wno-maybe-uninitialized 7388427844Smrg 7488427844Smrg This warning was introduced in an ancient GCC but was 7588427844Smrg significantly enhanced in GCC 10, unfortunately, many of 7688427844Smrg the new instances are incorrect. 7788427844Smrg 78c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_MAYBE_UNINITIALIZED} 7988427844Smrg 8088427844Smrg -Wno-return-local-addr 8188427844Smrg 8288427844Smrg This warning was introduced in GCC 5 and was enhanced in GCC 8388427844Smrg 10. Unfortunately, the new instances are failing to correctly 8488427844Smrg analyze code flow and miss that most of the are handled. 8588427844Smrg 86c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_RETURN_LOCAL_ADDR} 8788427844Smrg 8888427844Smrg 8988427844Smrgnew GCC 9 warnings: 9088427844Smrg 9188427844Smrg -Wno-address-of-packed-member 9288427844Smrg 9388427844Smrg This warning was introduced in GCC 8. 9488427844Smrg This warning is similar to -Wformat-truncation, but for the 9588427844Smrg general family of string functions (str*(), etc.), and has 9688427844Smrg similar issues of false positives. 9788427844Smrg 98f937c412Slukem bsd.own.mk variable: ${CC_WNO_ADDRESS_OF_PACKED_MEMBER} 9988427844Smrg 10088427844Smrg 10188427844Smrgnew GCC 8 warnings: 10288427844Smrg 10388427844Smrg -Wstringop-truncation 10488427844Smrg 10588427844Smrg This warning was introduced in GCC 8. 10688427844Smrg This warning is similar to -Wformat-truncation, but for the 10788427844Smrg general family of string functions (str*(), etc.), and has 10888427844Smrg similar issues of false positives. 10988427844Smrg 110c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_STRINGOP_TRUNCATION} 11188427844Smrg 11288427844Smrg 11388427844Smrg -Wcast-function-type 11488427844Smrg 11588427844Smrg This warning was introduced in GCC 8. 11688427844Smrg This warning can find real problems. Most instances are 11788427844Smrg false positives, and hopefully this warning will become 11888427844Smrg more useful in the future. See __FPTRCAST(). 11988427844Smrg 120c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_CAST_FUNCTION_TYPE} 12188427844Smrg 12288427844Smrg 12388427844Smrgnew GCC 7 warnings: 12488427844Smrg 12588427844Smrg -Wstringop-overflow 12688427844Smrg 12788427844Smrg This warning was introduced in GCC 7. 12888427844Smrg This warning can find issues where source length is 12988427844Smrg passed as destination length (eg, strncpy() where the 13088427844Smrg length is strlen(src)) that are potential buffer overflow 13188427844Smrg cases and should always be inspected, but false positives 13288427844Smrg are also seen. 13388427844Smrg 134c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_STRINGOP_OVERFLOW} 13588427844Smrg 13688427844Smrg 13788427844Smrg -Wformat-truncation 13888427844Smrg 13988427844Smrg This warning was introduced in GCC 7. 14088427844Smrg This warning has many false positives where truncation is 14188427844Smrg either expected or unavoidable, but also finds several real 14288427844Smrg code bugs. 14388427844Smrg 14488427844Smrg Code should always be manually inspected for this warning 14588427844Smrg as it does pick up real issues. 14688427844Smrg 147c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_FORMAT_TRUNCATION} 14888427844Smrg 14988427844Smrg 15088427844Smrg -Wformat-overflow 15188427844Smrg 15288427844Smrg This warning was introduced in GCC 7. 15388427844Smrg This warning typically identifies a real problem, but it may 15488427844Smrg fail to notice the code handles this case. 15588427844Smrg 15688427844Smrg Code should always be manually inspected for this warning 15788427844Smrg as it does pick up real issues. 15888427844Smrg 159c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_FORMAT_OVERFLOW} 16088427844Smrg 16188427844Smrg 16288427844Smrg -Wimplicit-fallthrough 16388427844Smrg 16488427844Smrg This warning was introduced in GCC 7. 16588427844Smrg This warning has many false positives in GCC 7, and many are 16688427844Smrg fixed in newer GCC 10. Old uses should be checked occasionally. 16788427844Smrg 16888427844Smrg Code should always be manually inspected for this warning 16988427844Smrg as it does pick up real issues. 17088427844Smrg 171c4b7a9e7Slukem bsd.own.mk variable: ${CC_WNO_IMPLICIT_FALLTHROUGH} 172