<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>The logfile from the WineHQ Ubuntu 21.04 build on OBS is here:<br></div><div><a href="https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/wine-devel/_log">https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/wine-devel/_log</a><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Do you have a "sample warning" for me to search for? Eg. <!--StartFragment--><pre>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=]</pre><!--EndFragment--> <br data-mce-bogus="1"></div><div>Sveinar<br data-mce-bogus="1"></div><div><br></div><div><span id="zwchr" data-marker="__DIVIDER__">----- On Sep 29, 2021, at 11:17 AM, Eric Pouech <eric.pouech@orange.fr> wrote:<br></span></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><p><font face="Helvetica, Arial, sans-serif">For sharing :</font></p>
<p><font face="Helvetica, Arial, sans-serif">- newest gcc version
(11) sets by default of bunch of new tests for code correctness</font></p>
<p><font face="Helvetica, Arial, sans-serif">- it spits out around
ten thousand lines of warnings (*), making it quite impossible
to look into compiler output</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">there are a couple of
genuine issues reported by gcc11</font></p>
<p><font face="Helvetica, Arial, sans-serif">- Rémi and I already
sent a serie of patches for addressing those<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">- a strange indentation
waiting for a volunteer</font></p>
<p><font face="Helvetica, Arial, sans-serif"> (in dlls/</font><font face="Helvetica, Arial, sans-serif">wininet/internet.c:2878, the
line </font><br>
<font face="Helvetica, Arial, sans-serif">
lpwhh->ErrorMask = *(ULONG*)lpBuffer;<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif"> at the end of the
if/else chain is misindented)</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">unfortunately, most of
the generated warnings are false positives, that need to be
fixed (or removerd) before GCC11 becomes mainstream</font></p>
<p><font face="Helvetica, Arial, sans-serif">- Fedora 35 with GCC11
is in beta right now, and GA is mid of October</font></p>
<p><font face="Helvetica, Arial, sans-serif">- I haven't checked
other distros though, but I expect similar evolution in coming
weeks/months</font></p>
<p><font face="Helvetica, Arial, sans-serif">- in Fedora both gcc
and mingw-gcc have been upgraded to version 11</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">The false positives we
need to tackle:</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">A) misleading
indentation</font></p>
<p><font face="Helvetica, Arial, sans-serif">===================<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">GCC11 complains about
code like:</font></p>
<p><font face="Helvetica, Arial, sans-serif"> foo;</font></p>
<p><font face="Helvetica, Arial, sans-serif">todo_wine</font></p>
<p><font face="Helvetica, Arial, sans-serif"> ok(tst, ...);</font></p>
<p><font face="Helvetica, Arial, sans-serif"><font face="Helvetica,
Arial, sans-serif"> </font>bar;</font></p>
<p>(gcc11 warns about 'bar ' not being properly indented wrt
todo_wine)</p>
<p>there are (as of today) 817 occurrences of those in wine tree
(spread across 127 files)</p>
<p>and counts for ~90% (*) of the line of warnings generated by GCC<br>
</p>
<p>only 2 true positives are generated by this GCC warning<br>
</p>
<br>
<p>Remarks:</p>
<p>- constructs on a single line don't generate the warning<br>
</p>
<p> todo_wine ok(tst, ...); // ok no warning, whatever the
indentation of the line wrt the rest of the code<br>
</p>
<p>- having the ok(tst, ...) inside a block after the todo_wine
doesn't generate the warning</p>
<p><br>
</p>
<p>possible solutions:</p>
<p>- disable the warning in configure</p>
cons: will not trigger on true positive<br>
<p> pros: minor impact on code base (either committed and under
progress in dev:s trees)<br>
</p>
<p>- merge the todo_wine and ok() line into a single one</p>
<p> pros: keep current indentation, coherent with todo_wine +
block</p>
<p> cons: harder to read, esp. for todo_wine_if<br>
</p>
<p> cons: for todo_wine_if, could generate too long lines</p>
<p> cons: large impact on code base<br>
</p>
<p> pros/cons: git blame on ok() line will tell who removed the
todo_wine, not who wrote the test</p>
<p>- reindent only problematic todo_wine<br>
</p>
<font face="Helvetica, Arial, sans-serif"> foo;</font>
<p><font face="Helvetica, Arial, sans-serif"> todo_wine</font></p>
<p><font face="Helvetica, Arial, sans-serif"> ok(tst, ...);</font></p>
<p><font face="Helvetica, Arial, sans-serif"><font face="Helvetica,
Arial, sans-serif"> </font>bar;</font></p>
^ without indenting the line ok(tst, ...);
<p> ^ without indenting the "todo_wine {\n<...>\n}" nor the
"todo_wine ok()" on a single line constructs as they don't
generate warnings<br>
</p>
<p> pros/cons: indentation isn't used for adding comments to the
code (that's what comments are for)<br>
</p>
<p> cons: large impact on code base<br>
</p>
<p>- reindent all todo_wine</p>
<p> same as above, but also reindenting the "todo_wine
{\n<...>\n}" and the "todo_wine ok()" on a single line
constructs</p>
<p> pros/cons: indentation isn't used for adding comments to the
code (that's what comments are for)<br>
</p>
<p> cons: large impact on code base<br>
</p>
<br>
<p><font face="Helvetica, Arial, sans-serif">B) uninitialized
objects<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">===============</font></p>
<p><font face="Helvetica, Arial, sans-serif">GCC11 warns on code
like:<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">void foo(const TYPE*
s);</font></p>
<p><font face="Helvetica, Arial, sans-serif">.....</font></p>
<p><font face="Helvetica, Arial, sans-serif">TYPE s;</font></p>
<p><font face="Helvetica, Arial, sans-serif">foo(&s);</font></p>
<p><font face="Helvetica, Arial, sans-serif">because, s isn't
initialized, and is passed as const ptr, hence could be read by
function foo without being initialized</font></p>
<p><font face="Helvetica, Arial, sans-serif">proposal:</font></p>
<p><font face="Helvetica, Arial, sans-serif">- depending on context,
different fixes are at hand: either initialize s, or when
applicable, play with aliasing<br>
</font></p>
<p>C) partial structures</p>
<p>============<br>
</p>
<p>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.</p>
<p>(roughly 400 lines of warnings (*))</p>
<p><br>
</p>
<p>It's used:</p>
<p>- when dealing with two structures sharing their first fields
(like in BITMAP for example)<br>
</p>
<p>- in tests, to test behavior will various sizes of objects as
input...</p>
<p><br>
</p>
<p>proposal: disable this warning in configure</p>
<p><br>
</p>
<p>D) sizeof/sizeof</p>
<p>=========<br>
</p>
<p>GCC11 warns when sizeof(foo)/sizeof(bar) is used and cannot be
reduced to computing the number of elements of an array</p>
<p>proposal: rewrite as sizeof(foo)/(sizeof(bar)) (note the
parenthesis around sizeof(bar), as suggested by GCC)</p>
<p><br>
</p>
<p>A+<br>
</p>
<p>
</p>
<p><br>
</p>
<p>(*) those values are rough estimates, only consider the order of
magnitude<br>
<font face="Helvetica, Arial, sans-serif"></font></p><br></blockquote></div></div></body></html>