From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: Re: #define __MUSL__ in features.h
Date: Thu, 15 Mar 2018 22:46:56 +0100 [thread overview]
Message-ID: <20180315214656.GX4418@port70.net> (raw)
In-Reply-To: <20180315193244.GK1436@brightrain.aerifal.cx>
* Rich Felker <dalias@libc.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.
next prev parent reply other threads:[~2018-03-15 21:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 15:55 dgutson .
2018-03-15 18:39 ` Rich Felker
2018-03-15 18:48 ` Martin Galvan
2018-03-15 18:53 ` Rich Felker
2018-03-15 19:00 ` dgutson .
2018-03-15 19:13 ` dgutson .
2018-03-15 19:42 ` Rich Felker
2018-03-15 20:16 ` u-uy74
2018-03-15 20:44 ` u-uy74
2018-03-15 19:37 ` Rich Felker
2018-03-15 19:42 ` dgutson .
2018-03-15 19:02 ` Martin Galvan
2018-03-15 19:32 ` Rich Felker
2018-03-15 19:37 ` dgutson .
2018-03-15 19:43 ` Rich Felker
2018-03-15 19:52 ` dgutson .
2018-03-15 21:46 ` Szabolcs Nagy [this message]
2018-03-15 22:38 ` Rich Felker
2018-03-15 18:51 ` dgutson .
2018-03-15 21:06 ` Markus Wichmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180315214656.GX4418@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).