Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Florian Weimer <fweimer@redhat.com>]

* Gerald Pfeifer:

> On Fri, 2 Feb 2024, Florian Weimer wrote:
>>  htdocs/gcc-14/porting_to.html | 465 ++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 465 insertions(+)
>> +
>> +<h4 id="int-conversion">Using pointers as integers and vice versa (<code>-Werror=int-conversion</code>)</h4>
>
>> +It makes sense to address missing <code>int</code> type, implicit
>
> Should this be plural here ("<code>int</code> types") or some adding a 
> word such as "declaration"? Genuine question.

“missing <code>int</code> type[s]” seems to be okay.

>> +Some of them will be caused by missing types resulting
>> +in <code>int</code>, and the default <code>int</code> return type of
>> +implicitly declared functions.
>
> ...resulting in implicit <code>int</code>... or something like that?
> Not sure how to be phrase it.

I went with: “missing types [treated as] <code>int</code>”

>> +GCC no longer casts all pointer types to all other pointer types.
>
> Do you mean it no longer does so implicitly, or not at all? That is,
> there are now cases where even an explicit cast such as
>
>   foo_p = (foo_type*) bar_p
>
> no longer works? Or just
>
>   foo_p = bar_p
>
> no longer works for all combinations?

The latter, other reviewers noted it as well, and I've got this now:
“GCC no longer [allows implicitly casting] all pointer types to all”

>> +appropriate casts, and maybe consider using code <code>void *</code>
>> +in more places (particularly for old programs that predate the
>> +introduction of <code>void</code> into the C language).
>
> Here I got confused.
>
> At first I thought I was reading that <code>void *</void> should be used 
> for cases where <code>void</void> did not exist yet. Now I think I 
> understand: this is about programs where <code>void *</code> was not used 
> since it was not part of the language yet - and the encouragement is to 
> update such old code by using it. 
>
> If so, how about making the second case <code>void *</code>, too?

Makes sense.  Technically you can't have void * without void,
but I can see this may be confusing.

>> +#include &lt;stddef.h>
>
> I *think* we may need to use &gt; here instead of plain '>', though I may 
> be wrong.

No, only &lt; needs to be quoted.  This is true even for XML, not just
HTML5.  Do you want me to change these to &gt;?

>> +<pre>
>> +int
>> +compare (<ins>const void *a1</ins>, <ins>const void *b1</ins>)
>> +{
>> +  <ins>char *const *a = a1;</ins>
>> +  <ins>char *const *b = b1;</ins>
>> +  return strcmp (*a, *b);
>> +}
>> +</pre>
>
> Great that you include this example here, that really helps!
>
> Just why "const void *a1" versus "char *const *a", that is, the different 
> placement of const?

It's the right type. 8-)  The examples uses an array of char *,
not const char *.

>> +unrelated to the actual objective of the probe.  These failed probes
>> +tend to consistently disable program features and their tests, which
>> +means that an unexpected probe failure may result in silently dropping
>> +features.
>
> Omit "consistently"? I'm not sure what it adds here. And simplify the 
> second half, something like
>
>   These failed probes tend to disable program features (and their tests), 
>   resulting in silently dropping features.

What about this?

   These failed probes tend to disable program features [together with]
   their tests[], resulting in silently dropping features.

This what I meant with “consistently”: implementations and tests are
gone, so the testsuite doesn't flag it.

>> +In cases where this is a concern, generated <code>config.log</code>,
>> +<code>config.h</code> and other source code files can be compared
>> +using <a href="https://www.gnu.org/software/diffutils/">diff</a>,
>> +to ensure there are no unexpected differences.
>
> I wouldn't link to GNU diffutils here; just refer to the <code>diff</code> 
> command - or even omit that aspect and leave it at "can be compared".

diff is really useful for that, manual comparison isn't. 8-)
I can drop the hyperlink.

>> +Some build systems do not pass the <code>CFLAGS</code> environment
>> +or <code>make</code> variable to all parts of the builds
>
> Is "make" a common variable? What is the context here?

Hmm, I meant to allude $(CFLAGS) here.

“<code>CFLAGS</code> [] variable to all parts of the builds” should be
sufficient.

>> +<p>
>> +It is unclear at which point GCC can enable the C23 <code>bool</code>
>> +keyword by default (making the <code>bool</code> type available
>> +without including <code>#include &lt;stdbool.h></code> explicitly).
>
> Does C every include some header files implicitly?

GCC does, for <stdc-predef.h>.  Not relevant here, though.

> For the benefit of the doubt: Okay, and thank you, modulo feedback from 
> Jonathan and my two responses.

Thank you for your review.

I need to add two more code examples to the Autoconf section, should I
post a v2 with that, or add that in a subsequent commit?

Florian