This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wwwdocs] changes.html - document new warning options
Wow, that's quite a patch. And quite some contributions behind that! :-)
Let me offer some comments, and then I suggest you commit what you
have (taking these comments into account), and we can still improve
things then if there is further feedback.
Index: gcc-7/changes.html
===================================================================
+ <li>GCC 7 can determine the return value or range of return values of
+ some calls to the <code>sprintf</code> family of functions and make
+ it available to other optimization passes. Some calls to the <code>
+ snprintf</code> function with a zero size argument can be folded
Formatting here appears a little odd? I wouldn't have that line break
afer <code>.
+ into constants. The optimization is included in <code>-O1</code>
+ and can be selectively controlled by the
"This optimization"
+<li>GCC 7 contains a number of enhancements that help detect buffer overflow
+ and other forms of invalid memory accesses.
"buffer overflows" (plural) ?
+ errors. Such bugs have been known to be the source of
+ vulnerabilities and a target of exploits.
Perhaps say "security vulnerabilities"? Not sure about that.
+ <code>-Walloc-size-larger-than=<i>PTRDIFF_MAX</i></code> is included
+ in <code>-Wall</code>.</p>
PTRDIFF_MAX without <i>...</i> I would say, since it's not a variable.
+ <p>For example, the following call to <b>malloc</b> incorrectly tries
<code>malloc</code>
+void* f (int n)
+{
+ return malloc (n > 0 ? 0 : n);
+}
Great example! :-)
+ <li><p>The <code>-Walloc-zero</code> option detects calls to standard
+ and user-defined memory allocation functions decorated with attribute
+ <code>alloc_size</code> with a zero argument. <code>-Walloc-zero</code>
+ is not included in either <code>-Wall</code> or <code>-Wextra</code>
+ and must be explicitly enabled.</p></li>
Why are you adding <p> within <li>? This should not be necessary.
+ <b><code>sprintf</code></b> is diagnosed because even though its
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why <b>...</b> here?
+ output has been constrained using the modulo operation it could
+ result in as many as three bytes if <code>mday</code> were negative.
+ The solution is to either allocate a larger buffer or make sure
+ the argument is not negative, for example by changing <code>mday</code>'s
+ type to <code>unsigned</code> or by making the type of the second operand
+ of the modulo expression to <code>unsigned</code>: <code>100U</code>.
"changing the type"
+ <code>-Wformat-overflow=<i>1</i></code> is included in
No <i>...</i> around 1, since it's a constant (not a variable).
+ <code>nonnull</code>). By taking advantage of optimization the option
+ can detect many more cases of the problem than in prior GCC
+ versions.</p></li>
"optimizations" (Or "compiler optimizations", to avoid ambiguity
whether the option was optimized or is now leveraging compiler
optimizations?)
+ <li><p>The <code>-Wstringop-overflow=<i>type</i></code> option detects
+ buffer overflow in calls to string manipulation functions like
"overflows"
+ <code>memcpy</code> and <code>strcpy</code>. The option relies
Is memcpy really a string manipulation function?
+ on Object Size Checking and has an effect similar to defining
+ the <code>_FORTIFY_SOURCE</code> macro.
Naive question: What is "Object Size Checking", and where is it
introduced or desribed?
+ <code>-Wstringop-overflow=<i>1</i></code> is enabled by default.</p>
No <i>s around constants.
+ <p>For example, in the following snippet, because the call to
+ <code>strncat</code> specifies a maximum that allows the function to
+ write past the end of the destination, it is diagnosed. To correct
+ the problem and avoid the overflow the function should be called
+ with a size of at most <code>sizeof d - strlen(d)</code>.
I'm getting tired this evening, but is this taking care of the \0
being added? Or would that require sizeof d - strlen(d) - 1?
Gerald