[PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

Martin Sebor msebor@gmail.com
Fri Aug 7 17:01:31 GMT 2020


On 7/29/20 12:12 PM, Joseph Myers wrote:
> On Tue, 28 Jul 2020, Martin Sebor via Gcc-patches wrote:
> 
>> +  /* A list of VLA variable bounds or null if not specified.  */
>> +  tree vbchain = NULL_TREE;
>> +  if (parm->declarator->kind == cdk_array)
> 
>> +	  if (pd->kind != cdk_array)
>> +	    break;
> 
>> +	      /* Skip all constant bounds except the most significant
>> +		 one.  The interior ones are included in the array type.  */
>> +	      if (next && next->kind == cdk_array)
>> +		continue;
> 
> Anything working with declarators should typically have logic to skip
> cdk_attrs declarators.

Thanks for the quick review/reply and the hints below!

> For example, a parameter is declared as an array using [] in that
> declarator if the innermost c_declarator that is not cdk_id or cdk_attrs
> is of kind cdk_array.  (It's the innermost not the outermost because of C
> declarator syntax.)  The array bounds for the parameter array itself (as
> opposed to any other bounds if the parameter is e.g. an array of pointers
> to arrays) are then those in all the cdk_array declarators after the last
> declarator (if any) that's not cdk_array, cdk_attrs or cdk_id (cdk_id only
> comes in the last place).
> 
> If e.g. the parameter has the nested cdk_declarator sequence
> 
> cdk_function
> cdk_pointer
> cdk_array
> cdk_attrs
> cdk_array
> cdk_pointer
> cdk_array
> cdk_attrs
> cdk_array
> cdk_array
> cdk_id
> 
> then it's a three-dimensional array of pointers to two-dimensional arrays
> of pointers to functions.
> 
> I don't see anything in the tests in this patch to cover this sort of case
> (arrays of pointers, including arrays of pointers to arrays etc.).

I've added a few test cases and reworked the declarator parsing
(get_parm_array_spec) a bit, fixing some bugs.

While testing I also noticed a problem/limitation in the array/VLA
formatting function that I couldn't think of how to fix without
duplicating a lot of what the C/C++ pretty printer does.  So
the updated patch also includes changes to the pretty printer to
do most of what I need.  As may be evident from the comments, I'm
not very happy with the solution but my only other idea was to add
a bit to an array type to indicate whether it's [static N] or [*]
and that seems too intrusive.  If you find the "hack" I put in
unacceptable for the initial patch I'd appreciate a suggestion
for a cleaner approach.  I'd like to  fix that in a followup
patch.

The pretty printer formatting only produces [*] for the most
significant unspecified VLA bound, and the whole machinery
ignores [static] on VLA bounds.  I'd like to fix both but I
thought I'd get your suggestion for how to make [*] appear
in inner bounds first.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-50584-2.diff
Type: text/x-patch
Size: 59233 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200807/c954b16e/attachment-0001.bin>


More information about the Gcc-patches mailing list