Re: Problems with large records (GNAT) [continued]

[Robert A Duff <bobduff@world.std.com>]

Dr Adrian Wrigley <amtw@linuxchip.demon.co.uk> writes:

> You might remember a while back I had a problem with 'Size failing
> on large types, using GNAT (3.12p Intel Linux (Red Hat 6.2)).

No.  But then I haven't read comp.lang.ada in months.  ;-)

> I never managed to solve that problem, and made do with keeping
> all my records under 256MB (!).

I'm curious: Why do you need such enormous records?
And if your data structures are almost as big as your 32-bit address
space, why don't you get a machine with a 64-bit address space?

> This time, I have come across another manifestation of the problem,
> which appears rather strange.  The locations for different
> elements in a record are the same.  In the example code below,
> the elements First and Last are stored in the same place.
> (you can verify this using 'Access on the two elements).

They're not aliased in the code below, so 'Access isn't allowed.
Perhaps you meant 'Address?

Anyway, I can't explain that problem, but...

>    X := Malloc (Interfaces.C.Size_T (Size * Float'Size + 2*Float'Size)); -- Hmmmm

Float'Size is in bits, whereas malloc expects a size in bytes
(or in units of sizeof(char), or whatever).

You need to divide by System.Storage_Unit, and you need to write your
code carefully to avoid overflow, since you're dealing with numbers
close to Integer'Last.

Why are you using malloc anyway?  Why not "X := new Item_t;"?

- Bob

P.S. If you think you've found a bug in GNAT, report it, and maybe
they'll fix it.