diff mbox

[wwwdocs] changes.html - document new warning options

Message ID 28b0b2d5-4636-7465-5381-6c8750f5a6df@gmail.com
State New
Headers show

Commit Message

Martin Sebor Jan. 31, 2017, 3:57 p.m. UTC
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

Comments

Aldy Hernandez Jan. 31, 2017, 5:30 p.m. UTC | #1
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 :).
diff mbox

Patch

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>