On Thu, 15 Feb 2024, Florian Weimer wrote: >>> +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”
Ah, got it. The wording above nicely clarifies it to me. I am wondering whether "...every point type to every other pointer type" might be even more clear? (Open question, "no" being a very valid answer.) >> 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 >? No, no; if it validates, we're good. :-) > 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. I like 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. Yes, I never would compare manually myself. :) Let's drop the hyperlink then; people developing software would know diff. >>> +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. Ah, reading this again I see it was "environment variable" or "make variable" - the beauty of natural languages and their ambiguity. Yes, your suggested edit looks good! > 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? Primarily as you prefer. My personal recommendation (not request) is to commit the current patch and then add on top. Thanks again for your work documenting all this! Gerald
