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. -uwe