Generic access type convention and aliasing

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Hi people,

Things are working as expected, but I still wonder and welcome other's  
feeling on the topic.

I have a generic memory allocator, which is instantiated with a  
constrained object type (objects of an average size ranging from 10 to 20  
KB) and an access type to that object type. The object type is typically  
an array type with fixed bounds (statically known constraints).


     generic
        Element_Type is private;
        Element_Access is access Element_Type;
     package Allocators
        …
     end;


In the generic declaration, I'm not allowed to express the requirement on  
the access type to use the C convention.


     Element_Access is access Element_Type
        with Convention => C;
        -- Not allowed: generic types can't specify
        -- a representation clause.


An allocator returns the allocation result in a discriminated record  
looking like this:


     type Result_Type (Allocated : Boolean := False) is
        record
           case Allocated is
              when False =>
                 null;
              when True =>
                 Element : Element_Access
                    with Convention => C;
           end case;
        end record;


I'm not allowed to add a representation requirement to the generic access  
parameter type, but GNAT let me specify the C convention for a variable  
(*) of that type in the record type.

I don't want the variable in the record to be simply of type  
`Element_Access` as‑is, and so even if the type is fully constrained and  
there is no unavoidable technical needs for storing any constraint data at  
the address designated by the access variable; I prefer it to be explicit,  
so the `Convention => C`.

Do you believe it's enough to be safe? Is it enough for preventing any  
compiler to believe there may be constraints data stored at the address  
designated by the access type, and so even if the generic parameter does  
not enforce it?

Or should I also give the C convention to each access types used to  
instantiate this generic? That's an option, but I don't like it: there is  
no way to enforce it, so it is not safe to me; too much easy to forget  
without any way to make the compiler flag it.

(*) A variable which I would enjoy to force to be a constant after record  
initialization, but I can't; another story.


The second question I optionally wonder about. I initially created the  
access variable value using `Ada.Unchecked_Conversion` applied to a  
numeric type (as indeed, the result I retrieve is numeric, because it may  
be an error status instead of an address, depending on the range the  
result belongs to). But GNAT did not enjoyed this and complained the  
resulting access type returned by the unchecked conversion, may present  
aliasing problem. The memory is allocated with `mmap` using `MAP_PRIVATE`,  
so there is no risk of aliasing (except in case of nasty OS failure), but  
I could not make GNAT understand it (*). I worked around it using a  
two‑instructions assembly procedure to do the conversion from the numeric  
type to the access type (to an access variable with convention C). I don't  
really expect there exist a way to tell GNAT the access does not present  
aliasing issues, but still worth to ask for it if ever on the contrary  
there exist a way to tell it.


(*) It just stop complaining if I added `pragma No_Strict_Aliasing  
(Element_Access)`, but that's not a way to tell it there is no risk of  
aliasing with that access type: the contrary.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University