On Fri, 2 Feb 2024, Florian Weimer wrote: > +<h3 id="warnings-as-errors">Certain warnings are now errors</h3>
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 <p>...</p>? 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 <code>int</code> keyword > +addresses the error. For example, a flag like > + > +<pre> > + static initialized; > +</pre> > + > +might turn into: > + > +<pre> > + static <ins>int</ins> initialized; > +</pre> How about "For example, a variable like ... becomes"? > +<p>If the return type of a function is omitted, the correct type to > +add could be <code>int</code> or <code>void</code>, depending on > +whether the function returns a value or not. "can be" > +<p>In some cases, the previously implied <code>int</code> 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? > +<pre> > + <ins>void</ins> > + write_string (<ins>int</ins> fd, const char *s) <ins>const char</ins> *s) as well? > +Some programs are built with <code>-std=c11</code> or > +similar <code>-std</code> options that do not contain the > +string <code>gnu</code>, 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 <code>-Wdeclaration-missing-parameter-type</code> 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. > +<p> > +By default, GCC still accepts returning an expression of > +type <code>void</code> from within a function that itself > +returns <code>void</code>, 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,
