The logfile from the WineHQ Ubuntu 21.04 build on OBS is here: [ https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/... | https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/... ]
I could not immediately find warnings about what you are talking about here, but there sure is enough warnings about "format argument" (-Wformat and -Wstrict-aliasing) stuff, that i don't get when i compile wine myself locally. Might not be related to what you ask here, but since you were talking about "gcc 11 becomes mainstream", i thought it was worth to point to the official OBS buildlog for Ubuntu 21.04 - that uses gcc-11 (although gcc-mingw-w64 is still at 10.3).
I guess debian/ubuntu "debuild" system sets these -Wformat= and -Wstrict-aliasing options when building as default, and that seem to throw a lot of warnings. I did not browse through the entire log, but maybe it is just some overly eager checks that some distro's enable by default, that it is not really critical?
Do you have a "sample warning" for me to search for? Eg. dlls/ncrypt/main.c:106:11: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'NCRYPT_PROV_HANDLE' {aka 'long long unsigned int'} [-Wformat=]
Sveinar
----- On Sep 29, 2021, at 11:17 AM, Eric Pouech eric.pouech@orange.fr wrote:
For sharing :
- newest gcc version (11) sets by default of bunch of new tests for code
correctness
- it spits out around ten thousand lines of warnings (*), making it quite
impossible to look into compiler output
there are a couple of genuine issues reported by gcc11
- Rémi and I already sent a serie of patches for addressing those
- a strange indentation waiting for a volunteer
(in dlls/ wininet/internet.c:2878, the line lpwhh->ErrorMask = *(ULONG*)lpBuffer;
at the end of the if/else chain is misindented)
unfortunately, most of the generated warnings are false positives, that need to be fixed (or removerd) before GCC11 becomes mainstream
- Fedora 35 with GCC11 is in beta right now, and GA is mid of October
- I haven't checked other distros though, but I expect similar evolution in
coming weeks/months
- in Fedora both gcc and mingw-gcc have been upgraded to version 11
The false positives we need to tackle:
A) misleading indentation
===================
GCC11 complains about code like:
foo;
todo_wine
ok(tst, ...);
bar;
(gcc11 warns about 'bar ' not being properly indented wrt todo_wine)
there are (as of today) 817 occurrences of those in wine tree (spread across 127 files)
and counts for ~90% (*) of the line of warnings generated by GCC
only 2 true positives are generated by this GCC warning
Remarks:
- constructs on a single line don't generate the warning
todo_wine ok(tst, ...); // ok no warning, whatever the indentation of the line wrt the rest of the code
- having the ok(tst, ...) inside a block after the todo_wine doesn't generate
the warning
possible solutions:
- disable the warning in configure cons: will not trigger on true positive
pros: minor impact on code base (either committed and under progress in dev:s trees)
- merge the todo_wine and ok() line into a single one
pros: keep current indentation, coherent with todo_wine + block
cons: harder to read, esp. for todo_wine_if
cons: for todo_wine_if, could generate too long lines
cons: large impact on code base
pros/cons: git blame on ok() line will tell who removed the todo_wine, not who wrote the test
- reindent only problematic todo_wine
foo;
todo_wine
ok(tst, ...);
bar; ^ without indenting the line ok(tst, ...);
^ without indenting the "todo_wine {\n<...>\n}" nor the "todo_wine ok()" on a single line constructs as they don't generate warnings
pros/cons: indentation isn't used for adding comments to the code (that's what comments are for)
cons: large impact on code base
- reindent all todo_wine
same as above, but also reindenting the "todo_wine {\n<...>\n}" and the "todo_wine ok()" on a single line constructs
pros/cons: indentation isn't used for adding comments to the code (that's what comments are for)
cons: large impact on code base
B) uninitialized objects
===============
GCC11 warns on code like:
void foo(const TYPE* s);
.....
TYPE s;
foo(&s);
because, s isn't initialized, and is passed as const ptr, hence could be read by function foo without being initialized
proposal:
- depending on context, different fixes are at hand: either initialize s, or
when applicable, play with aliasing
C) partial structures
============
In a bunch of places, we use a pointer to a structure, where underlying allocated object is smaller than the actual size of the structure.
(roughly 400 lines of warnings (*))
It's used:
- when dealing with two structures sharing their first fields (like in BITMAP
for example)
- in tests, to test behavior will various sizes of objects as input...
proposal: disable this warning in configure
D) sizeof/sizeof
=========
GCC11 warns when sizeof(foo)/sizeof(bar) is used and cannot be reduced to computing the number of elements of an array
proposal: rewrite as sizeof(foo)/(sizeof(bar)) (note the parenthesis around sizeof(bar), as suggested by GCC)
A+
(*) those values are rough estimates, only consider the order of magnitude