Re: Allocators design flaw

[Victor Porton <porton@narod.ru>]

Simon Wright wrote:

> Victor Porton <porton@narod.ru> writes:
> 
>> The Ada problem is that that _alloc_memory() cannot be integrated with
>> Ada allocators. The problem is that (in principle) Ada may request a
>> greater alignment than C ever has, and this way Ada allocators become
>> incompatible with C.
> 
> I just don't understand what the problem is.
> 
> If you declared an access type in Ada and invoked new, it's possible
> (really only in the context of the AI I referenced earlier) that the
> allocation might require an alignment greater than that required for the
> basic data. The AI's first example is
> 
>        type T is access String;
>        for T'Storage_Pool use ... ;
>        X : T := new String'("abc");

The trouble is as follows:

There is nothing in Ada standard to prevent the above "new" operator to 
request 256-byte alignment of the data. (Yes, I know this does not happen in 
practice, but it is not forbidden by the RM.)

If it requests such a great alignment by the C function *_alloc_memory() is 
able to do only 16-byte alignment, then my allocator would break the 
contract, that is allocate with lesser alignment than requested.

This could in principle lead to undefined behavior.

>     In the case of an access type whose designated subtype is an
>     unconstrained array subtype, some implementations prepend contiguous
>     dope information to the allocated array. String'Alignment is
>     typically 1. If the dope information contains values of the array
>     type's index type(s), then the alignment requirement of this dope
>     information might reasonably be that of the most strictly aligned
>     index type. The given example might be easier to implement if the
>     implementation were allowed to pass Integer'Alignment instead of
>     String'Alignment as the Alignment parameter in the call to Allocate
>     associated with the allocator.

The above quotation is unrelated.

> If you then called Unchecked_Deallocation, it would need to be aware of
> this extra dope information.

Again unrelated.

> But you don't propose to invoke new, which means that

Why? I do propose to invoke new.

> System.Storage_Pools.Allocate isn't going to be called. You're going to
> get C to allocate the memory as appropriate for whatever it contains,

What I want is to write Allocate in such a way that it could work calling 
the C allocating function.

> including any dope information, and if the Ada side gets to see its
> contents it will do so via appropriate representation clauses, which
> will explicitly include any dope information.
> 
> I agree that if the C side allocates the memory with an alignment that's
> incompatible with the contents of the struct then you'll have a problem,
> but I don't see how that could possibly be cured from the Ada side.

"C side" allocated memory compatible with every C struct. This is not the 
problem.

The problem that Ada may request a greater (a natural number of times) 
alignment and the C function cannot do what Ada requests.

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