Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
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 config.log, >>> +config.h and other source code files can be compared >>> +using https://www.gnu.org/software/diffutils/;>diff, >>> +to ensure there are no unexpected differences. >> I wouldn't link to GNU diffutils here; just refer to the diff >> 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 CFLAGS environment >>> +or make variable to all parts of the builds >> >> Is "make" a common variable? What is the context here? > Hmm, I meant to allude $(CFLAGS) here. > > “CFLAGS [] 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
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
On Thu, 15 Feb 2024, Florian Weimer wrote: >> Naive questions: Can definitions really be prototypes (in C)? > Yes, I think so: definitions can be declarations, and function > prototypes are declarations. The standard uses the phrase “function > definition that does not include a function prototype declarator”. > Should I write “old-style function definition” instead? I think that would have helped me (as a not too much of a language expert). Only make that change if you think it makes sense, though. >>> +GCC will type-check function arguments after that, potentially >>> +requiring further changes. (Previously, the function declaration was >>> +treated as not having no prototype.) >> That second sentence uses double negation, which logically is the same as >> just the original statement. > Other reviews suggests to change it to “not having [a] prototype”. Ah, let's use that then. >>> +By default, GCC still accepts returning an expression of >>> +type void from within a function that itself >>> +returns void, as a GNU extension that matches C++ rules >>> +in this area. > Does the GNU extension match C++ (standard rules)? > Yes. Should I write “matches [standard] C++ rules”? Looks good to me. (At first I was confused, but I guess this is a GNU extension to the C standard - that matches standard C++ in this area?) Gerald
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
* Gerald Pfeifer: > On Fri, 2 Feb 2024, Florian Weimer wrote: >> +Certain warnings are now errors > > That's quite a nice description, thank you, Florian! > >> +The initial ISO C standard and its 1999 revision removed support for > > May I suggest to wrap paragraphs in ...? Not strictly necessary any > more, now that we switched to HTML 5, though more consistent and explicit. I've tried this now, and adds extra whitespace in some cases, for example here: “ In most cases, simply adding the missing int keyword addresses the error. For example, a flag variable like static initialized; becomes: static int initialized; ” I would have to nest the in the , which suggests a complexity that just isn't there. Thanks, Florian
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
* Gerald Pfeifer:
> On Fri, 2 Feb 2024, Florian Weimer wrote:
>> htdocs/gcc-14/porting_to.html | 465
>> ++
>> 1 file changed, 465 insertions(+)
>> +
>> +Using pointers as integers and vice versa
>> (-Werror=int-conversion)
>
>> +It makes sense to address missing int type, implicit
>
> Should this be plural here ("int types") or some adding a
> word such as "declaration"? Genuine question.
“missing int type[s]” seems to be okay.
>> +Some of them will be caused by missing types resulting
>> +in int, and the default int return type of
>> +implicitly declared functions.
>
> ...resulting in implicit int... or something like that?
> Not sure how to be phrase it.
I went with: “missing types [treated as] int”
>> +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 void *
>> +in more places (particularly for old programs that predate the
>> +introduction of void into the C language).
>
> Here I got confused.
>
> At first I thought I was reading that void * should be used
> for cases where void did not exist yet. Now I think I
> understand: this is about programs where void * 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 void *, 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 ?
>> +
>> +int
>> +compare (const void *a1, const void *b1)
>> +{
>> + char *const *a = a1;
>> + char *const *b = b1;
>> + return strcmp (*a, *b);
>> +}
>> +
>
> 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 config.log,
>> +config.h and other source code files can be compared
>> +using https://www.gnu.org/software/diffutils/;>diff,
>> +to ensure there are no unexpected differences.
>
> I wouldn't link to GNU diffutils here; just refer to the diff
> 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 CFLAGS environment
>> +or make variable to all parts of the builds
>
> Is "make" a common variable? What is the context here?
Hmm, I meant to allude $(CFLAGS) here.
“CFLAGS [] variable to all parts of the builds” should be
sufficient.
>> +
>> +It is unclear at which point GCC can enable the C23 bool
>> +keyword by default (making the bool type available
>> +without including #include stdbool.h> explicitly).
>
> Does C every include some header files implicitly?
GCC does, for . 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
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
* Gerald Pfeifer: >> This mostly happens in function definitions >> +that are not prototypes > > Naive questions: Can definitions really be prototypes (in C)? Yes, I think so: definitions can be declarations, and function prototypes are declarations. The standard uses the phrase “function definition that does not include a function prototype declarator”. Should I write “old-style function definition” instead? > >> +declared outside the parameter list. Using the correct >> +type maybe required to avoid int-conversion errors (see below). > > Something feels odd with this sentence? The fix is to write “may[ ]be“, as suggested by other reviewers. >> +Incorrectly spelled type names in function declarations are treated as >> +errors in more cases, under a >> +new -Wdeclaration-missing-parameter-type warning. The >> +second line in the following example is now treated as an error >> +(previously this resulted in an unnamed warning): > > What is an "unnamed" warning? Can we simply omit "unnamed" here? A warning not controlled by a specific -W… option. I've made the change. >> +GCC will type-check function arguments after that, potentially >> +requiring further changes. (Previously, the function declaration was >> +treated as not having no prototype.) > > That second sentence uses double negation, which logically is the same as > just the original statement. Other reviews suggests to change it to “not having [a] prototype”. >> + >> +By default, GCC still accepts returning an expression of >> +type void from within a function that itself >> +returns void, as a GNU extension that matches C++ rules >> +in this area. > > Does the GNU extension match C++ (standard rules)? Yes. Should I write “matches [standard] C++ rules”? Thanks, Florian
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
Florian Weimer writes: > * Sam James: > >> It's fine if you leave this out, but consider mentioning the common >> pitfall of autoconf projects not including config.h consistently before >> all inclues. We could also mention AC_USE_SYSTEM_EXTENSIONS. > > I added: > > “ > Alternatively, projects using using Autoconf > could enable AC_USE_SYSTEM_EXTENSIONS. > ” > > inclusion is a larger issue, I think, best addressed by > future diagnostics. OK, works for me. We should discuss some options for the latter at some point though (I think we could do it for libc cases where it matters for LFS at least) but that's for another time. > >>> + >>> +When building library code on GNU systems, it was possible to call >>> +undefined (not just undeclared) functions and still run other code in >>> +the library, particularly if ELF lazy binding was used. Only >>> +executing the undefined function call would result in a lazy binding >>> +error and program crash. >> >> Maybe explicitly refer to the bfd linker's relaxed behaviour so it >> sounds less mysterious. > > Like this? > > “ > > When building library code on GNU systems, > href="https://sourceware.org/binutils/docs-2.42/ld/Options.html#index-_002d_002dallow_002dshlib_002dundefined;>it > was possible to call > undefined (not just undeclared) functions > and still run other code in the library, particularly if ELF lazy binding > was used. Only executing the undefined function call would result in a > lazy binding error and program crash. > ” Sounds good, thanks. > > Thanks, > Florian best, sam signature.asc Description: PGP signature
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
* Sam James: > It's fine if you leave this out, but consider mentioning the common > pitfall of autoconf projects not including config.h consistently before > all inclues. We could also mention AC_USE_SYSTEM_EXTENSIONS. I added: “ Alternatively, projects using using Autoconf could enable AC_USE_SYSTEM_EXTENSIONS. ” inclusion is a larger issue, I think, best addressed by future diagnostics. >> + >> +When building library code on GNU systems, it was possible to call >> +undefined (not just undeclared) functions and still run other code in >> +the library, particularly if ELF lazy binding was used. Only >> +executing the undefined function call would result in a lazy binding >> +error and program crash. > > Maybe explicitly refer to the bfd linker's relaxed behaviour so it > sounds less mysterious. Like this? “ When building library code on GNU systems, https://sourceware.org/binutils/docs-2.42/ld/Options.html#index-_002d_002dallow_002dshlib_002dundefined;>it was possible to call undefined (not just undeclared) functions and still run other code in the library, particularly if ELF lazy binding was used. Only executing the undefined function call would result in a lazy binding error and program crash. ” Thanks, Florian
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
* Jonathan Wakely: >>+To fix the remaining int-conversions issues, add casts >>+to an appropriate pointer or integer type. On GNU systems, the >>+standard (but generally optional) types > > I know what you mean here, but I'm not sure the parenthesis adds > clarity for anybody who doesn't already know that those types are > optional for conformance. I think they're supported for all targets > that GCC supports, so maybe just omit the parenthesis. Fair enough, I've droped the parentheses. Thank you for your other suggestions as well, I have applied them. Florian
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
Hi Florian,
that's been quite a bit. Thank you for putting this together so
comprehensively and thoughtfully, with examples and background!
Note many of my points are suggestions or questions, especially if phrased
as questions or using maybe or similar, so for your consideration.
On Fri, 2 Feb 2024, Florian Weimer wrote:
> htdocs/gcc-14/porting_to.html | 465
> ++
> 1 file changed, 465 insertions(+)
> +
> +Using pointers as integers and vice versa
> (-Werror=int-conversion)
> +It makes sense to address missing int type, implicit
Should this be plural here ("int types") or some adding a
word such as "declaration"? Genuine question.
> +Some of them will be caused by missing types resulting
> +in int, and the default int return type of
> +implicitly declared functions.
...resulting in implicit int... or something like that?
Not sure how to be phrase it.
> + Note that in some cases, it may be more appropriate to pass the
> +address of an integer variable instead of a cast of the variable's
> +value.
I'd omit the comma here since I don't feel the added emphasis is
necessary.
(And maybe simply say "In some cases it may..."?)
> +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?
> +To fix the compilation errors resulting from that, you can add the
"To fix compilation errors..."
> +appropriate casts, and maybe consider using code void *
> +in more places (particularly for old programs that predate the
> +introduction of void into the C language).
Here I got confused.
At first I thought I was reading that void * should be used
for cases where void did not exist yet. Now I think I
understand: this is about programs where void * 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 void *, too?
> +Programs that do not carefully track pointer types are likely to
> +contain aliasing violations, so consider building
> +with -fno-strict-aliasing as well.
I suggest omitting "as well" here.
> (Whether the casts
> +are written manually or performed by GCC automatically does not make a
> +difference in terms of strict aliasing violations.)
Here I'd just say "Whether casts are", omitting "the".
> +#include stddef.h>
I *think* we may need to use here instead of plain '>', though I may
be wrong.
> +To correct this, the callback function should be defined with the
> +correct type
"To address this ... be defined with the correct type"
(To avoid the double "correct"ion.)
> +
> +int
> +compare (const void *a1, const void *b1)
> +{
> + char *const *a = a1;
> + char *const *b = b1;
> + return strcmp (*a, *b);
> +}
> +
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?
And should it be "const void **a1" and similarly for "b1"??
> +As mentioned initially, adding the cast here would not eliminate any
> +strict aliasing violation in the implementation of
> +the operate function.
Really great you are pointing this out explicitly; thank you!
> +It may be possible to avoid writing manual casts with
> +the -fplan9-extensions options and unnamed
...option... (singular)
> +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.
> +In cases where this is a concern, generated config.log,
> +config.h and other source code files can be compared
> +using https://www.gnu.org/software/diffutils/;>diff,
> +to ensure there are no unexpected differences.
I wouldn't link to GNU diffutils here; just refer to the diff
command - or even omit that aspect and leave it at "can be compared".
> +This phenomenon also impacts similar procedures part of CMake, Meson,
> +and various build tools for C extension modules of scripting
> +languages.
"...procedures in CMake..."?
> +
> +Autoconf has supported C99 compilers since at least version 2.69 in
> +its generic, core probes. (Specific functionality probes may have
> +issues addressed in more recent versions.) Versions before 2.69 may
> +have generic probes (for example for standard C support) that rely on
> +C features that were removed in 1999 and thus fail with GCC 14.
"...removed in C99..."? As opposed to compilers removing them in 1999?
> +Sources that cannot be ported to
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
On Fri, 2 Feb 2024, Florian Weimer wrote: > +Certain warnings are now errors That's quite a nice description, thank you, Florian! > +The initial ISO C standard and its 1999 revision removed support for May I suggest to wrap paragraphs in ...? Not strictly necessary any more, now that we switched to HTML 5, though more consistent and explicit. > [For backwards] > +compatibility, GCC 13 and earlier compiler versions diagnosed use of > +these features as warnings only. Although these warnings have been > +enabled by default for many releases, experience shows that these > +warnings are easily ignored, resulting in difficult-to-diagnose bugs. Can we just say "GCC 13 and earlier" (or "GCC 13 and earlier versions")? And "...shows that they are easily ignored, resulting in difficult to diagnose bugs"? > +Several GNU/Linux distributions have shared patches from their porting > +efforts on relevant upstream mailing lists and bug trackers, but of > +course there is a strong overlap between programs that have these > +historic C compatibility issues and are dormant today. At first I thought something is missing here, then I realized it may be a difference between German (which also is my mother tongue) and English. One way to address it would be saying "and those that are dormant", though I believe something like ...but of course many programs that exhibit these historic C compatibility issues are dormant today. > +In most cases, simply adding the missing int keyword > +addresses the error. For example, a flag like > + > + > + static initialized; > + > + > +might turn into: > + > + > + static int initialized; > + How about "For example, a variable like ... becomes"? > +If the return type of a function is omitted, the correct type to > +add could be int or void, depending on > +whether the function returns a value or not. "can be" > +In some cases, the previously implied int type > +was not correct. I'd omit the comma here. > This mostly happens in function definitions > +that are not prototypes Naive questions: Can definitions really be prototypes (in C)? > +declared outside the parameter list. Using the correct > +type maybe required to avoid int-conversion errors (see below). Something feels odd with this sentence? > + > + void > + write_string (int fd, const char *s) const char *s) as well? > +Some programs are built with -std=c11 or > +similar -std options that do not contain the > +string gnu, but these programs still use POSIX or other ...but still use... (omit "these programs") > +If undeclared functions from the same project are called and there is > +yet no suitable shared header file, you should add a declaration to a "no suitable shared header file yet, you can add..." > +However, this is an obsolete C feature that will change meaning in C23 > +(declaration a function with a prototype and accepting no arguments, > +similar to C++). "declaration of a function", or some other change here? > +Incorrectly spelled type names in function declarations are treated as > +errors in more cases, under a > +new -Wdeclaration-missing-parameter-type warning. The > +second line in the following example is now treated as an error > +(previously this resulted in an unnamed warning): What is an "unnamed" warning? Can we simply omit "unnamed" here? > +GCC will type-check function arguments after that, potentially > +requiring further changes. (Previously, the function declaration was > +treated as not having no prototype.) That second sentence uses double negation, which logically is the same as just the original statement. > + > +By default, GCC still accepts returning an expression of > +type void from within a function that itself > +returns void, as a GNU extension that matches C++ rules > +in this area. Does the GNU extension match C++ (standard rules)? Wee, this is a patch. All the more kudos to you.. I'll be looking into the second half of the patch tomorrow; feel free to commit the aspects covered above (after considering my review). Cheers,
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
Florian Weimer writes:
> ---
> htdocs/gcc-14/porting_to.html | 465
> ++
> 1 file changed, 465 insertions(+)
>
Can't approve but LGTM. Thank you for being so thorough - it'll be
helpful when showing upstreams.
> diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
> index 3e4cedc3..4c8f9c8f 100644
> --- a/htdocs/gcc-14/porting_to.html
> +++ b/htdocs/gcc-14/porting_to.html
> @@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify
> common issues
> and provide solutions. Let us know if you have suggestions for improvements!
>
>
> +C language issues
> +
> +Certain warnings are now errors
> +
> + cite="https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
> + Function prototyping was added, first to help enforce type checking
> + on both the types of the arguments passed to the function, and also
> + to check the assignment compatibility of the function return type.
> +
> +Standard C: The ANSI Draft Grows Up.
> + PC Magazine, September 13, 1988, page 117.
> +
> +
> +
> +The initial ISO C standard and its 1999 revision removed support for
> +many C language features that were widely known as sources of
> +application bugs due to accidental misuse. For backwards
> +compatibility, GCC 13 and earlier compiler versions diagnosed use of
> +these features as warnings only. Although these warnings have been
> +enabled by default for many releases, experience shows that these
> +warnings are easily ignored, resulting in difficult-to-diagnose bugs.
> +In GCC 14, these issues are now reported as errors, and no output file
> +is created, providing clearer feedback to programmers that something
> +is wrong.
> +
> +
> +Most components of the GNU project have already been fixed for
> +compatibility, but not all of them have had releases since fixes were
> +applied. Programs that bundle parts
> +of https://www.gnu.org/software/gnulib/;>gnulib or
> +https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
> +may need to update these sources files from their upstream versions.
> +
> +
> +Several GNU/Linux distributions have shared patches from their porting
> +efforts on relevant upstream mailing lists and bug trackers, but of
> +course there is a strong overlap between programs that have these
> +historic C compatibility issues and are dormant today.
> +
> +Implicit int types
> (-Werror=implicit-int)
> +
> +In most cases, simply adding the missing int keyword
> +addresses the error. For example, a flag like
> +
> +
> + static initialized;
> +
> +
> +might turn into:
> +
> +
> + static int initialized;
> +
> +
> +If the return type of a function is omitted, the correct type to
> +add could be int or void, depending on
> +whether the function returns a value or not.
> +
> +In some cases, the previously implied int type
> +was not correct. This mostly happens in function definitions
> +that are not prototypes, when argument types are not
> +declared outside the parameter list. Using the correct
> +type maybe required to avoid int-conversion errors (see below).
maybe -> may be
> +In the example below, the type of s should be
> +const char *, not int:
> +
> +
> + write_string (fd, s)
> + {
> +write (1, s, strlen (s));
> + }
> +
> +
> +The corrected standard C source code might look like this (still
> +disregarding error handling and short writes):
> +
> +
> + void
> + write_string (int fd, const char *s)
> + {
> +write (1, s, strlen (s));
> + }
> +
> +
> +Implicit function declarations
> (-Werror=implicit-function-declaration)
> +
> +It is no longer possible to call a function that has not been
> +declared. In general, the solution is to include a header file with
> +an appropriate function prototype. Note that GCC will perform further
> +type checks based on the function prototype, which can reveal further
> +type errors that require additional changes.
> +
> +
> +For well-known functions declared in standard headers, GCC provides
> +fix-it hints with the appropriate #include directives:
> +
> +
> +error: implicit declaration of function ‘strlen’
> [-Wimplicit-function-declaration]
> +5 | return strlen (s);
> + | ^~
> +note: include ‘string.h>’ or provide a declaration of ‘strlen’
> + +++ |+#include string.h>
> +1 |
> +
> +
> +
> +On GNU systems, headers described in standards (such as the C
> +standard, or POSIX) may require the definition of certain
> +macros at the start of the compilation before all required
> +function declarations are made available.
> +See href="https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
> Test Macros
> +in the GNU C Library manual for details.
> +
> +
> +Some programs are built with -std=c11 or
> +similar -std options that do not contain the
> +string gnu, but these programs still use POSIX or other
> +extensions in standard C headers such as stdio.h>.
> +The GNU C library
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify
common issues
and provide solutions. Let us know if you have suggestions for improvements!
+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
+ Function prototyping was added, first to help enforce type checking
+ on both the types of the arguments passed to the function, and also
+ to check the assignment compatibility of the function return type.
+
+Standard C: The ANSI Draft Grows Up.
+ PC Magazine, September 13, 1988, page 117.
+
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse. For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only. Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied. Programs that bundle parts
+of https://www.gnu.org/software/gnulib/;>gnulib or
+https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error. For example, a flag like
+
+
+ static initialized;
+
+
+might turn into:
+
+
+ static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct. This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list. Using the correct
+type maybe required to avoid int-conversion errors (see below).
+In the example below, the type of s should be
+const char *, not int:
+
+
+ write_string (fd, s)
+ {
+write (1, s, strlen (s));
+ }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+ void
+ write_string (int fd, const char *s)
+ {
+write (1, s, strlen (s));
+ }
+
+
+Implicit function declarations
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared. In general, the solution is to include a header file with
+an appropriate function prototype. Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’
[-Wimplicit-function-declaration]
+5 | return strlen (s);
+ | ^~
+note: include ‘string.h>’ or provide a declaration of ‘strlen’
+ +++ |+#include string.h>
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as stdio.h>.
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same project are called
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 3e4cedc3..4c8f9c8f 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify
common issues
and provide solutions. Let us know if you have suggestions for improvements!
+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
+ Function prototyping was added, first to help enforce type checking
+ on both the types of the arguments passed to the function, and also
+ to check the assignment compatibility of the function return type.
+
+Standard C: The ANSI Draft Grows Up.
+ PC Magazine, September 13, 1988, page 117.
+
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse. For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only. Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied. Programs that bundle parts
+of https://www.gnu.org/software/gnulib/;>gnulib or
+https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error. For example, a flag like
+
+
+ static initialized;
+
+
+might turn into:
+
+
+ static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct. This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list. Using the correct
+type maybe required to avoid int-conversion errors (see below).
s/maybe/may be/
+In the example below, the type of s should be
+const char *, not int:
+
+
+ write_string (fd, s)
+ {
+write (1, s, strlen (s));
+ }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+ void
+ write_string (int fd, const char *s)
+ {
+write (1, s, strlen (s));
+ }
+
+
+Implicit function declarations
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared. In general, the solution is to include a header file with
+an appropriate function prototype. Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’
[-Wimplicit-function-declaration]
+5 | return strlen (s);
+ | ^~
+note: include ‘string.h>’ or provide a declaration of ‘strlen’
+ +++ |+#include string.h>
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as stdio.h>.
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same
