On Thu, Feb 13, 2020 at 15:03:35 +0100, Kamil Rytarowski wrote:

> On 13.02.2020 14:50, Valery Ushakov wrote:
> > On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
> > 
> > Can you show the original problem that you are trying to fix here?
> > When and how did you get warning?
> GCC has a property (as called by Joerg bug) that different backend,
> different optimization levels etc emit different warnings.
> There is a request from certain people around to fix GCC not to mute
> down GCC, only because warnings are emitted in one configuration and not
> in their build settings.
> I redirect these complains to GCC upstream.
> dhcpcd emits these warnings once we enable -fsanitize=undefined.

If I add -fsanitize=undefined to the command line to compile that file
(in current) I still do not see that warning.  I didn't have time yet
to do a full build with sanitizer enabled.

Arguably, if the tool you use is broken, you shouln't be mutilating
the source code just to shut that tool up.  In general I'm quite
worried about the recent ongoing activity of sprinkling changes around
the tree just to shut up this or that warning without paying much
attention to the end result.  Some of those changes were wrong. Some
left code looking inconsistent as they fixed one place that did
produce a warning, but didn't change nearly identical bits of code
just next to it that didn't.  That leaves code in a fractured state.
Casts in particular are a very blunt instrument, and given that
history of recent changes your use of that instrument in this case
really raised red flags.

If -- and I still haven't seen it myself, "works for me" in a naive
test -- -fsanitize=undefined is buggy w.r.t. -Wconversion, then you
should arange to use say -Wno-error=conversion for that specific file
when -fsanitize=undefined is enabled, we do have makefile machinery
for that.  This way the bug in the tool is not causing random and
dubious changes to the code, and is confined to a properly commented
change in a Makefile.


Reply via email to