[wwwdocs] changes.html - document new warning options

[wwwdocs] changes.html - document new warning options

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Attached is an update documenting a number of options new or updated
in GCC 7.  Aldy, if/when you have a minute can you please quickly look
over the -Waloca text to make sure I didn't miss something?

   -Walloca
   -Walloca-larger-than
   -Walloc-size-larger-than
   -Walloc-zero
   -Wformat-overflow
   -Wformat-truncation
   -Wnonnull
   -Wstringop-overflow

Thanks
Martin

[-- Attachment #2: gcc-7-changes.diff --]
[-- Type: text/x-patch, Size: 7934 bytes --]

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.39
diff -u -r1.39 changes.html
--- changes.html	17 Jan 2017 21:26:31 -0000	1.39
+++ changes.html	24 Jan 2017 19:57:27 -0000
@@ -40,11 +40,15 @@
 
 <!-- .................................................................. -->
 <h2 id="general">General Optimizer Improvements</h2>
-<!--
 <ul>
-  <li></li>
+  <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
+    into constants.  The optimization is included in <code>-O1</code>
+    and can be selectively controlled by the
+    <code>-fprintf-return-value</code> option.</li>
 </ul>
--->
 
 <!-- .................................................................. -->
 <h2 id="languages">New Languages and Language specific improvements</h2>
@@ -186,6 +190,125 @@
  enum operation { add, <span class="boldcyan">count</span> };
                        <span class="boldcyan">^~~~~</span></pre></blockquote>
 </li>
+<li>GCC 7 contains a number of enhancements that help detect buffer overflow
+  and other forms of invalid memory accesses.
+  <ul>
+    <li><p>The <code>-Walloc-size-larger-than=<i>size</i></code> option
+	detects calls to standard and user-defined memory allocation
+	functions decorated with attribute <code>alloc_size</code> whose
+	argument exceeds the specified <code><i>size</i></code>
+	(<code>PTRDIFF_MAX</code> by default).  The option also detects
+	arithmetic overflow in the computation of the size in two-argument
+	allocation functions like <code>calloc</code> where the total size
+	is the product of the two arguments.  Since calls with an excessive
+	size cannot succeed they are typically the result of programing
+	errors.  Such bugs have been known to be the source of
+	vulnerabilities and a target of exploits.
+      <code>-Walloc-size-larger-than=<i>PTRDIFF_MAX</i></code> is included
+      in <code>-Wall</code>.</p>
+      <p>For example, the following call to <b>malloc</b> incorrectly tries
+	to avoid passing a negative argument to the function and instead ends
+	up unconditionally invoking it with an argument less than or equal
+	to zero.  Since after conversion to the type of the argument of the
+      function (<code>size_t</code>) a negative argument results in a value
+      in excess of the maximum <code>PTRDIFF_MAX</code> the call is diagnosed.
+      <blockquote><pre>
+void* f (int n)
+{
+  return malloc (n > 0 ? 0 : n);
+}
+
+<span class="boldmagenta">warning: </span>argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [<span class="boldmagenta">-Walloc-size-larger-than=</span>]</pre></blockquote></p></li>
+    <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>
+    <li><p>The <code>-Walloca</code> option detects all calls to the
+	<code>alloca</code> function in the program.  <code>-Walloca</code>
+	is not included in either <code>-Wall</code> or <code>-Wextra</code>
+	and must be explicitly enabled.</p></li>
+    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option detects
+	calls to the <code>alloca</code> function whose argument may exceed
+	the specified <code><i>size</i></code>.
+	<code>-Walloca-larger-than</code> is not included in either
+	<code>-Wall</code> or <code>-Wextra</code> and must be explicitly
+	enabled.</p>
+      <p>For example, compiling the following snippet with
+	<code>-Walloca-larger-than=1024</code> results in a warning because
+	even though the code appears to call <code>alloca</code> only with
+	sizes of 1kb and less, since <code>n</code> is signed, a negative
+	value would result in a call to the function well in excess of
+	the limit.
+      <blockquote><pre>
+void f (int n)
+{
+  char *d;
+  if (n < 1025)
+    d = alloca (n);
+  else
+    d = malloc (n);
+  &hellip;
+}
+
+<span class="boldmagenta">warning: </span>argument to '<b>alloca</b> may be too large due to conversion from '<b>int</b>' to '<b>long unsigned int</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote></p></li>
+    <li><p>The <code>-Wformat-overflow=<i>level</i></code> option detects certain
+      and likely buffer overflow in calls to the <code>sprintf</code> family
+      of formatted output functions.  Although the option is enabled even
+      without optimization it works best with <code>-O2</code> and higher.</p>
+      <p>For example, in the following snippet the call to
+      <b><code>sprintf</code></b> is diagnosed because even though its
+      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>.
+      <blockquote><pre>
+void* f (int mday)
+{
+  char *buf = malloc (3);
+  sprintf (buf, "%02i", mday % 100);
+  return buf;
+}
+
+<span class="boldmagenta">warning: </span>'<b>sprintf</b> may write a terminating nul past the end of the destination [<span class="boldmagenta">-Wformat-overflow=</span>]
+<span class="boldcyan">note: </span>'<b>sprintf</b>' output between 3 and 4 bytes into a destination of size 3</pre></blockquote></p></li>
+    <li><p>The <code>-Wformat-truncation=<i>level</i></code> option detects
+	certain and likely output truncation in calls to the
+	<code>snprintf</code> family of formatted output functions.
+	<code>-Wformat-overflow=<i>1</i></code> is included in
+	<code>-Wall</code> and enabled without optimization but works best
+	with <code>-O2</code> and higher.</p></li>
+    <li><p>The <code>-Wnonnull</code> option has been enhanced to detect
+	a broader set of cases of passing null pointers to functions that
+	expect a non-null argument (those decorated with attribute
+	<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>
+    <li><p>The <code>-Wstringop-overflow=<i>type</i></code> option detects
+	buffer overflow in calls to string manipulation functions like
+	<code>memcpy</code> and <code>strcpy</code>. The option relies
+	on Object Size Checking and has a similar effect to defining
+	the <code>_FORTIFY_SOURCE</code> macro.
+	<code>-Wstringop-overflow=<i>1</i></code> is enabled by default.</p>
+      <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>.
+	<blockquote><pre>
+void f (const char *fname)
+{
+  char d[8];
+  strncpy (d, "/tmp/", sizeof d);
+  strncat (d, fname, sizeof d);
+}
+
+<span class="boldmagenta">warning: </span>specified bound 8 equals the size of the destination [<span class="boldmagenta">-Wstringop-overflow=</span>]</pre>
+	</blockquote></p></li>
+  </ul>
+</li>
 <li>The <code>&lt;limits.h&gt;</code> header provided by GCC defines
   macros such as <code>INT_WIDTH</code> for the width in bits of
   integer types, if <code>__STDC_WANT_IEC_60559_BFP_EXT__</code> is

Re: [wwwdocs] changes.html - document new warning options

[Aldy Hernandez]

On 01/24/2017 03:07 PM, Martin Sebor wrote:

Hi Martin.

Thank you for taking care of this.

> +    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option detects
> +	calls to the <code>alloca</code> function whose argument may exceed
> +	the specified <code><i>size</i></code>.
> +	<code>-Walloca-larger-than</code> is not included in either
> +	<code>-Wall</code> or <code>-Wextra</code> and must be explicitly
> +	enabled.</p>

You should probably document that we warn, not just on arguments that 
exceed a specific threshold, but arguments that are unbounded or unknown 
at compile time:

foo (size_t n)
{
	...
	p = alloca(n);
	...
}

Thanks.
Aldy

Re: [wwwdocs] changes.html - document new warning options

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On 01/31/2017 03:50 AM, Aldy Hernandez wrote:
> On 01/24/2017 03:07 PM, Martin Sebor wrote:
>
> Hi Martin.
>
> Thank you for taking care of this.
>
>> +    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option
>> detects
>> +    calls to the <code>alloca</code> function whose argument may exceed
>> +    the specified <code><i>size</i></code>.
>> +    <code>-Walloca-larger-than</code> is not included in either
>> +    <code>-Wall</code> or <code>-Wextra</code> and must be explicitly
>> +    enabled.</p>
>
> You should probably document that we warn, not just on arguments that
> exceed a specific threshold, but arguments that are unbounded or unknown
> at compile time:
>
> foo (size_t n)
> {
>     ...
>     p = alloca(n);
>     ...
> }

Sure.  I added a bit of text to the end of the sentence that should
hopefully make that clearer.  The updated patch is attached.

 >     <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option 
detects
 > 	calls to the <code>alloca</code> function whose argument either may
 > 	exceed the specified <code><i>size</i></code>, or that is not known
 > 	to be sufficiently constrained to avoid exceeding it.


Let me know if you think it needs more work.

Martin

[-- Attachment #2: gcc-7-changes.diff --]
[-- Type: text/x-patch, Size: 7363 bytes --]

Index: htdocs/gcc-7/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.49
diff -r1.49 changes.html
43d42
< 
44a44,50
>   <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
>     into constants.  The optimization is included in <code>-O1</code>
>     and can be selectively controlled by the
>     <code>-fprintf-return-value</code> option.</li>
285a292,412
> <li>GCC 7 contains a number of enhancements that help detect buffer overflow
>   and other forms of invalid memory accesses.
>   <ul>
>     <li><p>The <code>-Walloc-size-larger-than=<i>size</i></code> option
> 	detects calls to standard and user-defined memory allocation
> 	functions decorated with attribute <code>alloc_size</code> whose
> 	argument exceeds the specified <code><i>size</i></code>
> 	(<code>PTRDIFF_MAX</code> by default).  The option also detects
> 	arithmetic overflow in the computation of the size in two-argument
> 	allocation functions like <code>calloc</code> where the total size
> 	is the product of the two arguments.  Since calls with an excessive
> 	size cannot succeed they are typically the result of programming
> 	errors.  Such bugs have been known to be the source of
> 	vulnerabilities and a target of exploits.
>       <code>-Walloc-size-larger-than=<i>PTRDIFF_MAX</i></code> is included
>       in <code>-Wall</code>.</p>
>       <p>For example, the following call to <b>malloc</b> incorrectly tries
> 	to avoid passing a negative argument to the function and instead ends
> 	up unconditionally invoking it with an argument less than or equal
> 	to zero.  Since after conversion to the type of the argument of the
>       function (<code>size_t</code>) a negative argument results in a value
>       in excess of the maximum <code>PTRDIFF_MAX</code> the call is diagnosed.
>       <blockquote><pre>
> void* f (int n)
> {
>   return malloc (n > 0 ? 0 : n);
> }
> 
> <span class="boldmagenta">warning: </span>argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [<span class="boldmagenta">-Walloc-size-larger-than=</span>]</pre></blockquote></p></li>
>     <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>
>     <li><p>The <code>-Walloca</code> option detects all calls to the
> 	<code>alloca</code> function in the program.  <code>-Walloca</code>
> 	is not included in either <code>-Wall</code> or <code>-Wextra</code>
> 	and must be explicitly enabled.</p></li>
>     <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option detects
> 	calls to the <code>alloca</code> function whose argument either may
> 	exceed the specified <code><i>size</i></code>, or that is not known
> 	to be sufficiently constrained to avoid exceeding it.
> 	<code>-Walloca-larger-than</code> is not included in either
> 	<code>-Wall</code> or <code>-Wextra</code> and must be explicitly
> 	enabled.</p>
>       <p>For example, compiling the following snippet with
> 	<code>-Walloca-larger-than=1024</code> results in a warning because
> 	even though the code appears to call <code>alloca</code> only with
> 	sizes of 1kb and less, since <code>n</code> is signed, a negative
> 	value would result in a call to the function well in excess of
> 	the limit.
>       <blockquote><pre>
> void f (int n)
> {
>   char *d;
>   if (n < 1025)
>     d = alloca (n);
>   else
>     d = malloc (n);
>   &hellip;
> }
> 
> <span class="boldmagenta">warning: </span>argument to '<b>alloca</b> may be too large due to conversion from '<b>int</b>' to '<b>long unsigned int</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote></p></li>
>     <li><p>The <code>-Wformat-overflow=<i>level</i></code> option detects
> 	certain and likely buffer overflow in calls to the <code>sprintf</code>
> 	family of formatted output functions.  Although the option is enabled
> 	even without optimization it works best with <code>-O2</code> and
> 	higher.</p>
>       <p>For example, in the following snippet the call to
>       <b><code>sprintf</code></b> is diagnosed because even though its
>       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>.
>       <blockquote><pre>
> void* f (int mday)
> {
>   char *buf = malloc (3);
>   sprintf (buf, "%02i", mday % 100);
>   return buf;
> }
> 
> <span class="boldmagenta">warning: </span>'<b>sprintf</b> may write a terminating nul past the end of the destination [<span class="boldmagenta">-Wformat-overflow=</span>]
> <span class="boldcyan">note: </span>'<b>sprintf</b>' output between 3 and 4 bytes into a destination of size 3</pre></blockquote></p></li>
>     <li><p>The <code>-Wformat-truncation=<i>level</i></code> option detects
> 	certain and likely output truncation in calls to the
> 	<code>snprintf</code> family of formatted output functions.
> 	<code>-Wformat-overflow=<i>1</i></code> is included in
> 	<code>-Wall</code> and enabled without optimization but works best
> 	with <code>-O2</code> and higher.</p></li>
>     <li><p>The <code>-Wnonnull</code> option has been enhanced to detect
> 	a broader set of cases of passing null pointers to functions that
> 	expect a non-null argument (those decorated with attribute
> 	<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>
>     <li><p>The <code>-Wstringop-overflow=<i>type</i></code> option detects
> 	buffer overflow in calls to string manipulation functions like
> 	<code>memcpy</code> and <code>strcpy</code>. The option relies
> 	on Object Size Checking and has an effect similar to defining
> 	the <code>_FORTIFY_SOURCE</code> macro.
> 	<code>-Wstringop-overflow=<i>1</i></code> is enabled by default.</p>
>       <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>.
> 	<blockquote><pre>
> void f (const char *fname)
> {
>   char d[8];
>   strncpy (d, "/tmp/", sizeof d);
>   strncat (d, fname, sizeof d);
> }
> 
> <span class="boldmagenta">warning: </span>specified bound 8 equals the size of the destination [<span class="boldmagenta">-Wstringop-overflow=</span>]</pre>
> 	</blockquote></p></li>
>   </ul>
> </li>

Re: [wwwdocs] changes.html - document new warning options

[Aldy Hernandez]

On 01/31/2017 10:57 AM, Martin Sebor wrote:
> On 01/31/2017 03:50 AM, Aldy Hernandez wrote:
>> On 01/24/2017 03:07 PM, Martin Sebor wrote:
>>
>> Hi Martin.
>>
>> Thank you for taking care of this.
>>
>>> +    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option
>>> detects
>>> +    calls to the <code>alloca</code> function whose argument may exceed
>>> +    the specified <code><i>size</i></code>.
>>> +    <code>-Walloca-larger-than</code> is not included in either
>>> +    <code>-Wall</code> or <code>-Wextra</code> and must be explicitly
>>> +    enabled.</p>
>>
>> You should probably document that we warn, not just on arguments that
>> exceed a specific threshold, but arguments that are unbounded or unknown
>> at compile time:
>>
>> foo (size_t n)
>> {
>>     ...
>>     p = alloca(n);
>>     ...
>> }
>
> Sure.  I added a bit of text to the end of the sentence that should
> hopefully make that clearer.  The updated patch is attached.
>
>>     <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option
> detects
>>     calls to the <code>alloca</code> function whose argument either may
>>     exceed the specified <code><i>size</i></code>, or that is not known
>>     to be sufficiently constrained to avoid exceeding it.

I'd like to see an example, if possible.  I'm a big fan of them :).

Pretty please :).

Re: [wwwdocs] changes.html - document new warning options

[Martin Sebor]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On 01/31/2017 10:30 AM, Aldy Hernandez wrote:
> On 01/31/2017 10:57 AM, Martin Sebor wrote:
>> On 01/31/2017 03:50 AM, Aldy Hernandez wrote:
>>> On 01/24/2017 03:07 PM, Martin Sebor wrote:
>>>
>>> Hi Martin.
>>>
>>> Thank you for taking care of this.
>>>
>>>> +    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option
>>>> detects
>>>> +    calls to the <code>alloca</code> function whose argument may
>>>> exceed
>>>> +    the specified <code><i>size</i></code>.
>>>> +    <code>-Walloca-larger-than</code> is not included in either
>>>> +    <code>-Wall</code> or <code>-Wextra</code> and must be explicitly
>>>> +    enabled.</p>
>>>
>>> You should probably document that we warn, not just on arguments that
>>> exceed a specific threshold, but arguments that are unbounded or unknown
>>> at compile time:
>>>
>>> foo (size_t n)
>>> {
>>>     ...
>>>     p = alloca(n);
>>>     ...
>>> }
>>
>> Sure.  I added a bit of text to the end of the sentence that should
>> hopefully make that clearer.  The updated patch is attached.
>>
>>>     <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option
>> detects
>>>     calls to the <code>alloca</code> function whose argument either may
>>>     exceed the specified <code><i>size</i></code>, or that is not known
>>>     to be sufficiently constrained to avoid exceeding it.
>
> I'd like to see an example, if possible.  I'm a big fan of them :).
>
> Pretty please :).

Since you ask so nicely I added another example but I'm afraid it
isn't terribly interesting:

   In contrast, a call to alloca that isn't bounded at all such as
   in the following function will elicit the warning below regardless
   of the size argument to the option.

   void f (size_t n)
   {
     char *d = alloca (n)
     ...
   }

   warning: unbounded use of 'alloca' [-Walloca-larger-than=]

Martin

[-- Attachment #2: gcc-7-changes.diff --]
[-- Type: text/x-patch, Size: 8506 bytes --]

Index: gcc-7/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.49
diff -u -r1.49 changes.html
--- gcc-7/changes.html	30 Jan 2017 14:04:20 -0000	1.49
+++ gcc-7/changes.html	31 Jan 2017 18:54:54 -0000
@@ -40,8 +40,14 @@
 
 <!-- .................................................................. -->
 <h2 id="general">General Optimizer Improvements</h2>
-
 <ul>
+  <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
+    into constants.  The optimization is included in <code>-O1</code>
+    and can be selectively controlled by the
+    <code>-fprintf-return-value</code> option.</li>
   <li>A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
   It can be enabled by using the <code>-fstore-merging</code> option and is
@@ -283,6 +289,138 @@
  enum operation { add, <span class="boldcyan">count</span> };
                        <span class="boldcyan">^~~~~</span></pre></blockquote>
 </li>
+<li>GCC 7 contains a number of enhancements that help detect buffer overflow
+  and other forms of invalid memory accesses.
+  <ul>
+    <li><p>The <code>-Walloc-size-larger-than=<i>size</i></code> option
+	detects calls to standard and user-defined memory allocation
+	functions decorated with attribute <code>alloc_size</code> whose
+	argument exceeds the specified <code><i>size</i></code>
+	(<code>PTRDIFF_MAX</code> by default).  The option also detects
+	arithmetic overflow in the computation of the size in two-argument
+	allocation functions like <code>calloc</code> where the total size
+	is the product of the two arguments.  Since calls with an excessive
+	size cannot succeed they are typically the result of programming
+	errors.  Such bugs have been known to be the source of
+	vulnerabilities and a target of exploits.
+      <code>-Walloc-size-larger-than=<i>PTRDIFF_MAX</i></code> is included
+      in <code>-Wall</code>.</p>
+      <p>For example, the following call to <b>malloc</b> incorrectly tries
+	to avoid passing a negative argument to the function and instead ends
+	up unconditionally invoking it with an argument less than or equal
+	to zero.  Since after conversion to the type of the argument of the
+      function (<code>size_t</code>) a negative argument results in a value
+      in excess of the maximum <code>PTRDIFF_MAX</code> the call is diagnosed.
+      <blockquote><pre>
+void* f (int n)
+{
+  return malloc (n > 0 ? 0 : n);
+}
+
+<span class="boldmagenta">warning: </span>argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [<span class="boldmagenta">-Walloc-size-larger-than=</span>]</pre></blockquote></p></li>
+    <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>
+    <li><p>The <code>-Walloca</code> option detects all calls to the
+	<code>alloca</code> function in the program.  <code>-Walloca</code>
+	is not included in either <code>-Wall</code> or <code>-Wextra</code>
+	and must be explicitly enabled.</p></li>
+    <li><p>The <code>-Walloca-larger-than=<i>size</i></code> option detects
+	calls to the <code>alloca</code> function whose argument either may
+	exceed the specified <code><i>size</i></code>, or that is not known
+	to be sufficiently constrained to avoid exceeding it.
+	<code>-Walloca-larger-than</code> is not included in either
+	<code>-Wall</code> or <code>-Wextra</code> and must be explicitly
+	enabled.</p>
+      <p>For example, compiling the following snippet with
+	<code>-Walloca-larger-than=1024</code> results in a warning because
+	even though the code appears to call <code>alloca</code> only with
+	sizes of 1kb and less, since <code>n</code> is signed, a negative
+	value would result in a call to the function well in excess of
+	the limit.
+      <blockquote><pre>
+void f (int n)
+{
+  char *d;
+  if (n < 1025)
+    d = alloca (n);
+  else
+    d = malloc (n);
+  &hellip;
+}
+
+<span class="boldmagenta">warning: </span>argument to '<b>alloca</b> may be too large due to conversion from '<b>int</b>' to '<b>long unsigned int</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote></p>
+      <p>In contrast, a call to <code>alloca</code> that isn't bounded at all
+	such as in the following function will elicit the warning below
+	regardless of the <code><i>size</i></code> argument to the option.
+	<blockquote><pre>
+void f (size_t n)
+{
+  char *d = alloca (n)
+  &hellip;
+}
+
+<span class="boldmagenta">warning: </span>unbounded use of '<b>alloca</b>' [<span class="boldmagenta">-Walloca-larger-than=</span>]</pre></blockquote></p></li>
+    <li><p>The <code>-Wformat-overflow=<i>level</i></code> option detects
+	certain and likely buffer overflow in calls to the <code>sprintf</code>
+	family of formatted output functions.  Although the option is enabled
+	even without optimization it works best with <code>-O2</code> and
+	higher.</p>
+      <p>For example, in the following snippet the call to
+      <b><code>sprintf</code></b> is diagnosed because even though its
+      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>.
+      <blockquote><pre>
+void* f (int mday)
+{
+  char *buf = malloc (3);
+  sprintf (buf, "%02i", mday % 100);
+  return buf;
+}
+
+<span class="boldmagenta">warning: </span>'<b>sprintf</b> may write a terminating nul past the end of the destination [<span class="boldmagenta">-Wformat-overflow=</span>]
+<span class="boldcyan">note: </span>'<b>sprintf</b>' output between 3 and 4 bytes into a destination of size 3</pre></blockquote></p></li>
+    <li><p>The <code>-Wformat-truncation=<i>level</i></code> option detects
+	certain and likely output truncation in calls to the
+	<code>snprintf</code> family of formatted output functions.
+	<code>-Wformat-overflow=<i>1</i></code> is included in
+	<code>-Wall</code> and enabled without optimization but works best
+	with <code>-O2</code> and higher.</p></li>
+    <li><p>The <code>-Wnonnull</code> option has been enhanced to detect
+	a broader set of cases of passing null pointers to functions that
+	expect a non-null argument (those decorated with attribute
+	<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>
+    <li><p>The <code>-Wstringop-overflow=<i>type</i></code> option detects
+	buffer overflow in calls to string manipulation functions like
+	<code>memcpy</code> and <code>strcpy</code>. The option relies
+	on Object Size Checking and has an effect similar to defining
+	the <code>_FORTIFY_SOURCE</code> macro.
+	<code>-Wstringop-overflow=<i>1</i></code> is enabled by default.</p>
+      <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>.
+	<blockquote><pre>
+void f (const char *fname)
+{
+  char d[8];
+  strncpy (d, "/tmp/", sizeof d);
+  strncat (d, fname, sizeof d);
+}
+
+<span class="boldmagenta">warning: </span>specified bound 8 equals the size of the destination [<span class="boldmagenta">-Wstringop-overflow=</span>]</pre>
+	</blockquote></p></li>
+  </ul>
+</li>
 <li>The <code>&lt;limits.h&gt;</code> header provided by GCC defines
   macros such as <code>INT_WIDTH</code> for the width in bits of
   integer types, if <code>__STDC_WANT_IEC_60559_BFP_EXT__</code> is

Re: [wwwdocs] changes.html - document new warning options

[Gerald Pfeifer]

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

Re: [wwwdocs] changes.html - document new warning options

[Martin Sebor]

On 01/31/2017 02:16 PM, Gerald Pfeifer wrote:
> 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.

Sounds good.

>
> 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>.

Sure.

>
> +    into constants.  The optimization is included in <code>-O1</code>
> +    and can be selectively controlled by the
>
> "This optimization"

Okay.

>
> +<li>GCC 7 contains a number of enhancements that help detect buffer overflow
> +  and other forms of invalid memory accesses.
>
> "buffer overflows" (plural) ?

Both are common in literature.  Google returns about 5,220 hits for
the string "detect buffer overflow and" and about 2,980 for the
singular, so I kept it as is.

>
> +	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.

Sure.

> +      <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.

Okay.

>
> +      <p>For example, the following call to <b>malloc</b> incorrectly tries
>
> <code>malloc</code>

Done.

>
> +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.

Only for consistency with the other list items where it separates
paragraphs (it made it easier for me to spot missing tags and such).
I removed from where it was redundant.

>
> +      <b><code>sprintf</code></b> is diagnosed because even though its
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Why <b>...</b> here?

It was a copy and paste typo.  I removed the tags.

>
> +      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"
>

Right, thanks.

> +	<code>-Wformat-overflow=<i>1</i></code> is included in
>
> No <i>...</i> around 1, since it's a constant (not a variable).

Done.

>
> +	<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?

The C standard calls all the functions in <string.h> (including memcpy)
string handling functions.  I'm not sure where I got "manipulation"
from.  I changed it to string handling though I'm not sure it's a big
improvement given that memcpy arguments need not be strings.

>
> +	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?

It's described in the GCC manual.  I added a link to it.

>
> +	<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?

It sure would!

I've committed the patch with the changes above (plus another example
to make Aldy extra happy).  Please let me know if you spot something
else that needs adjusting.

Thanks for the careful review (and debugging)!

Martin

Re: [wwwdocs] changes.html - document new warning options

[Aldy Hernandez]

> Since you ask so nicely I added another example but I'm afraid it
> isn't terribly interesting:
>
>   In contrast, a call to alloca that isn't bounded at all such as
>   in the following function will elicit the warning below regardless
>   of the size argument to the option.
>
>   void f (size_t n)
>   {
>     char *d = alloca (n)
>     ...
>   }
>
>   warning: unbounded use of 'alloca' [-Walloca-larger-than=]

I like it.  Thank you so much for taking care of all this.

Re: [wwwdocs] changes.html - document new warning options

[Jakub Jelinek]

On Wed, Feb 01, 2017 at 05:50:08AM -0500, Aldy Hernandez wrote:
> 
> > Since you ask so nicely I added another example but I'm afraid it
> > isn't terribly interesting:
> > 
> >   In contrast, a call to alloca that isn't bounded at all such as
> >   in the following function will elicit the warning below regardless
> >   of the size argument to the option.
> > 
> >   void f (size_t n)
> >   {
> >     char *d = alloca (n)

Missing semicolon after alloca (n)

> >     ...
> >   }
> > 
> >   warning: unbounded use of 'alloca' [-Walloca-larger-than=]
> 
> I like it.  Thank you so much for taking care of all this.

	Jakub

Re: [wwwdocs] changes.html - document new warning options

[Gerald Pfeifer]

On Tue, 31 Jan 2017, Martin Sebor wrote:
> Thanks for the careful review (and debugging)!

Thanks for taking the time to prepare all this to begin with. ;-)

On Wed, 1 Feb 2017, Jakub Jelinek wrote:
>>>   void f (size_t n)
>>>   {
>>>     char *d = alloca (n)
> Missing semicolon after alloca (n)

Martin might argue that this was covered by the ellipsis dots
in the following line ;-), but I admit that's a little tongue
in cheek and went ahead with the patch below.

Thanks for your careful reviews, Jakub!

Gerald

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.52
diff -u -r1.52 changes.html
--- changes.html	1 Feb 2017 10:16:47 -0000	1.52
+++ changes.html	1 Feb 2017 19:05:12 -0000
@@ -368,7 +368,7 @@
       <blockquote><pre>
 void f (size_t n)
 {
-  char *d = alloca (n)
+  char *d = alloca (n);
   &hellip;
 }