GCC 11

[Eric Pouech]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210929/82024090/attachment.htm>