* 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 <stddef.h>
>
> I *think* we may need to use > here instead of plain '>', though I may
> be wrong.
No, only < needs to be quoted. This is true even for XML, not just
HTML5. Do you want me to change these to >?
>> +<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 <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
