Date: Thu, 15 Mar 2018 22:46:56 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Re: #define __MUSL__ in features.h * Rich Felker <dalias@...c.org> [2018-03-15 15:32:44 -0400]: > Perhaps this should be documented more explicitly, but there is no > guarantee that building with -Werror[=anything except warnings which > are constraint violations in C] will succeed, especially when GCC is > not honoring its usual promise not to produce warnings for code > expanded from macros from -isystem paths. I did just test and indeed > the warning is produced with gcc 6.3.0. > how did you reproduce it? -Wsign-conversion (or -Wconversion) is not even enabled by -Wall -Wextra -pedantic because it has so many false positives. if the user really asked for this warning then i think it's reasonable to show it even if it's expanded via a system header macro, since the issue might be how the macro is called. i think the patch with type casts is not acceptable: if there is a real bug (negative fd is used) then instead of erroring out (preferably at compile time if the negative int is visible) the cast silently makes sure the bug goes undetected. adding compiler version and platform dependent pragmas is also unacceptable (the headers should be possible to parse and understood by whatever tool that knows the c language). what would be acceptable is some form of assertion that the fd must be positive, however it seems nobody cares about this warning so neither gcc nor clang tries to use available range information to see if conversion can ever change the result: if (d > 0) FD_SET(d,s); still warns. if users care about this warning they should first make sure the compilers dont emit false positives for such trivial cases.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ