Re: Two questions on arrays with size defined by variables

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 2/9/25 12:53, Janis Papanagnou wrote:

On 09.02.2025 18:46, Janis Papanagnou wrote:

[...] my test-wise - deliberately
wrong! - assignment to 'a[99]' produced also no compiler complaints,

 
BTW, it produced also no core dump or any other runtime error.
(But it is obviously severely wrong code anyway.)

 
Accessing an array beyond it's bounds has undefined behavior, whether or
not it is a VLA. "undefined behavior" means that the C standard imposes
no requirements on the behavior. In particular, it does not require a
diagnostic message, nor a core dump, nor any other kind of runtime error.
The standard says "undefined behavior" when there are some situations
where it can be arbitrarily difficult to identify violations of a rule
at compile time. That applies to this rule, because if pointers are
used, it can be quite difficult to confirm whether or not a given access
will violate this rule.
In this particular case. however, it would be trivial to detect the
violation, but none of the compilers I've tested do so.
When such code is accepted by an implementation, what is most likely to
happen is that the compiler will generate code that creates an array
containing "foobar", and which attempts to write a pointer to the first
element of that array to the location where a[99] should be, if a had at
least 100 elements. Depending upon what that piece of memory is being
used for, the results could be catastrophic, or completely innocuous, or
somewhere in-between.

Both gcc and tcc are supposed to allocate 'a' on the stack, below
normal variables.  99 is large enough that write to a[99] probably
is doing no harm to variables needed to finish the program, so
no observale effect.

I slightly modifed the program to:

int
main(void) {
   int n = 5;
   char * arr[n];
   for(int i = 0; i < 99; i++) {
       arr[i] = 0;
   }
   return 0;
}

After that tcc produces apparently infinite loop.  Program compiled
using 'gcc arr2.c' (I stored the program if file called 'arr2.c')
crashes.  Using 'gcc -O arr2.c' apparently optimizes stores to
nothing (arr is local and unused otherwise, so stores do not have
any defined observable effect).  Using 'tcc -b arr2.c' activates
bounds checking in tcc.  Due to this program exits with sensible
error message:

$ ./a.out
arr2.c:6: at main: BCHECK: 0x7ffc41829d08 is outside of the region
arr2.c:6: at main: RUNTIME ERROR: invalid memory access


--
                              Waldek Hebisch