[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
