This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/68065] Size calculations for VLAs can overflow


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065

--- Comment #20 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Undefined behavior when the type is created (not when an object of that 
type is declared or when sizeof is used) seems entirely in accordance with 
normal C practice in areas such as stack overflow[*] (that is, where the C 
standard fails to recognize limits in such areas but all implementations 
in practice have such limits, that's a defect in the C standard).

[*] The existence of stack limits cannot be deduced from the argument that 
all objects in C are required by the C standard to have addresses, because 
you can recurse, and even do Turing-complete computation, without creating 
any new objects.  Cf. <http://www.open-std.org/jtc1/sc22/wg14/12727>.

One way (for C) to get a check that is evaluated at the point where the 
size of the type is evaluated is to hook into how grokdeclarator stores 
array size expressions in *expr (other parts of the front end then ensure 
that *expr is evaluated at exactly the right time).  Instead of storing 
plain size expressions, it would be necessary to store a more complicated 
expression containing the checks.  *And* it would be necessary to put 
checks in there for the case where a constant-size array is declared but 
the elements of that array are of variable size, to make sure that 
overflow in the multiplication is detected in that case (right now, *expr 
is used only for variable size expressions, because they might have side 
effects so the time of evaluation matters).  This applies regardless of 
what the conditions are for when to enable such a check.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]