From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RISK_FREE autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cadf87a839d5869c,start X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 X-Received: by 10.66.121.4 with SMTP id lg4mr7255822pab.41.1367799615063; Sun, 05 May 2013 17:20:15 -0700 (PDT) Path: ln4ni1451pbb.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!newsfeed1.swip.net!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Generic access type convention and aliasing Date: Mon, 06 May 2013 02:20:03 +0200 Organization: Ada @ Home Message-ID: NNTP-Posting-Host: 01/BPNoqk8s7XmPzrYdoUA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.15 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 4777 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2013-05-06T02:20:03+02:00 List-Id: 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 2= 0 = 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 =E2=80=A6 end; In the generic declaration, I'm not allowed to express the requirement o= n = the access type to use the C convention. Element_Access is access Element_Type with Convention =3D> 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 :=3D False) is record case Allocated is when False =3D> null; when True =3D> Element : Element_Access with Convention =3D> C; end case; end record; I'm not allowed to add a representation requirement to the generic acces= s = 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=E2=80=91is, and so even if the type is fully constra= ined 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 explici= t, = so the `Convention =3D> 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 i= s = 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 recor= d = 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 ma= y = 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), bu= t = I could not make GNAT understand it (*). I worked around it using a = two=E2=80=91instructions assembly procedure to do the conversion from th= e 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. -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity