This is the mail archive of the gcc@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]

Re: Added error message (for too-large array)


    If the size cannot be represented in size_t, it isn't represented
    internally in gcc in any useful way; it overflows to some number bearing
    little relation to what the user intended.

Right, but TREE_OVERFLOW is set, so we *know* it has overflowed.

    It would think the Ada frontend should set TYPE_SIZE itself for such an
    ARRAY_TYPE, rather than let the middle-end come up with a meaningless
    value.

Why?  There's no meaningful value for it, set by anybody.  All you can do
with such a type is basically to take a pointer to it or use it to index
an array.  Any computation that needs the size is incorrect.

The place you typically see this in Ada is when you are passing things
to C and you want to make a "C-style" array but you are passing
variable-size data.  The normal idiom is to make any array whose
bounds are all non-negative integers.  But unless each array element
is only one byte long, this will overflow.  However, it's fine as long
as nothing needs the size.

But I still don't understand what motiviated this test.


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