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