Re: Undefined behavior in genautomata.c?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Sebastian Pop <sebastian.pop@cri.ensmp.fr> writes:

| Gabriel Dos Reis wrote:
| > 
| > If VRP is doing what you described in the comment as "its work", then
| > VRP is broken.  Period.  The fix is to fix VRP.  It is such a C
| > idomatic construct than I would not have expected any "optimizer" to
| > break it.  And that is very worrisome and scary.
| > 
| 
| Okay, VRP is not that broken in mainline, but only on a patch that I'm
| working on.
| 
| By the way, how is this different than detecting a bound on:
| 
| {
|   int foo[1335];
| 
|   for (i = 0; i < some_param; i++)
|     foo[i];
| }
| 
| vs.
| 
| {
|   some_struct{ int foo[1335];} s;
| 
|   for (i = 0; i < some_param; i++)
|     s.foo[i];
| }


There is a difference between what invariants you can derive by
looking at the declaration of an *object* -- like the automatic
objects in your example -- and invariants you can derive by looking
only at a structure definition in isolation.  In particular, a
structure can be used to define both an automatic object (for which
usually much stronger properties can be derived) and object from free
store -- which are not "declared object", consequently you have much
more "tricks" going on there:

     typedef struct {
        int data[1];
     } foo;

     foo* p = (foo *) malloc (sizeof (foo) + N * sizeof (int));
     // there are enough room for N ints, and the store is properly
     // aligned.

     for (int i = 0; i < N; ++i)
           p->data[i] = frobnicate (N, i);


The majority of C programs (I know of) that implement arrays use
similar trick.

-- Gaby