Re: Bug in GNAT? - Max_size_in_storage_elements insufficient

[Egil H H <ehh.public@gmail.com>]

Using Max_Size_In_Storage_Elements in this way is asking for trouble, and not at all portable, as the actual storage needed may depend on Alignment and fragmentation.
However, looking at GNAT's implementation (GNATPro 7.4.1), there are a couple quirks;

First off, the storage pool used by GNAT in this case ends up in a buffer on the stack. Unallocated parts of the buffer is implemented as a kind of overlayed linked list of chunks. This list always needs at least one root node, with a size field and pointer to the next node (on my 64 bit machine, the node is a total of 16 storage_elements), so that's several bytes worth of extra space needed, which 'Max_Size_In_Storage_Elements does not (and can not) take into account. I'll leave it up to AdaCore to answer whether this is the intended behaviour.

Secondly, when allocating an object in the pool, there is a search for a large enough chunk. This search checks if the chunk size is less than (not less than or equal to) the requested size + alignment. So the actual chunk selected must be at least one byte larger than requested, which must be a bug...

Knowing this, I got your code code working on my machine by doing
Storage_Size => (Num_Tasks * My_Task'Max_Size_In_Storage_Elements) + 17
This is of course not at all portable across compilers, not even across GNAT versions... And certainly not portable across machine architectures. 

So, one oddity and a likely bug... You may as well report it...

-- 
~egilhh