Re: Allocators design flaw

[Victor Porton <porton@narod.ru>]

Victor Porton wrote:

> It is impossible to properly implement an allocator through a C function
> (such as raptor_alloc_memory() from Raptor C library) which allocates a
> struct and returns the pointer to the allocated struct.
> 
> It is because RM13.11(21.5/3) "The Alignment parameter is a nonzero
> integral multiple of D'Alignment..."
> 
> (If it were "The Alignment parameter is equal to D'Alignment", then we
> would be able just to check (in Allocate procedure implementation) that
> 
> pragma Assert(Dummy_Record'Alignment mod Alignment = 0);
> -- where Dummy_Record is an arbitrary C-convention record
> -- (as all C records have the same alignment reqs)
> 
> So Alignment parameter may be arbitrarily big and the C function alignment
> may not conform to it.
> 
> Let us think how to work around (in Ada 202x) of this design flaw.

The best solution I found for my concrete problem (allocate a C struct with 
the C library allocating function raptor_alloc_memory() rather then with the 
standard storage pool) is:

Let the (C compatible) type of the struct be T.

Using raptor_alloc_memory() allocate a void* pointer for an object of size 
'Max_Size_In_Storage_Elements. Using some black magic () transform void* 
into an access to T.

See https://groups.google.com/forum/#!topic/comp.lang.ada/-xfDsAOMj5s
about the "black magic" to convert void* to an access.

(I need to use 'Max_Size_In_Storage_Elements for allocation size to be sure 
assignment to my object won't overflow anything, right?)

-- 
Victor Porton - http://portonvictor.org