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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6339fea48a1b8cda X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!eweka.nl!lightspeed.eweka.nl!213.239.142.2.MISMATCH!feed.xsnews.nl!border-1.ams.xsnews.nl!border1.nntp.ams.giganews.com!nntp.giganews.com!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Enumeration representation clause surprise. Date: Wed, 11 Jun 2008 21:37:06 -0500 Organization: Jacob's private Usenet server Message-ID: References: <0cbb6daf-01e9-40f5-855c-4f1d45cb0096@m73g2000hsh.googlegroups.com> <87abhs6qyj.fsf@willow.rfc1149.net> <55613982-679e-419d-8656-03b549393289@w4g2000prd.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1213239988 32641 69.95.181.76 (12 Jun 2008 03:06:28 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 12 Jun 2008 03:06:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-RFC2646: Format=Flowed; Response Xref: g2news1.google.com comp.lang.ada:663 Date: 2008-06-11T21:37:06-05:00 List-Id: "Markus Schoepflin" wrote in message news:g2oqld$qli$1@nntp.ilk.net... > Adam Beneschan wrote: >> On Jun 11, 6:28 am, Samuel Tardieu wrote: >>> Markus> This is exactly my point. I would have expected a compile time >>> error >>> Markus> for this impossible request. >>> >>> Markus> Representation clauses are (amongst other) meant to specify >>> specific >>> Markus> binary layouts for interfacing with the external world. Or am I >>> Markus> mistaken here? >>> >>> I can't find anything in RM chapter 13 which either forbids or allows >>> such a behaviour. I will submit a patch for GNAT which gives a new >>> warning for this case: >>> >>> 11. A1 at 0 range 0 .. 0; -- (*) >>> | >>> >>> warning: component representation will be biased >> >> This seems odd to me. Having GNAT select a biased component in >> Christoph's example makes some sense, since a compiler can choose any >> representation it likes. But in Markus' case, he specifically asked >> for a certain representation for the enumeration types---should GNAT >> take it upon itself to change that, and display a warning that doesn't >> make it clear that it's disrespecting his request to have the >> enumeration represented a certain way? > > Do you suggest to reword the warning? Or give an error instead? I agree with Adam (whose message I mysteriously didn't receive). Even if the letter of the RM allows this sort of behavior, it seems wrong from an expectation basis: an explicitly given representation clause is being ignored where there is a conflict between two of them. That's never a good thing. So I think this should be an error - a compiler shouldn't be changing explicitly given representation items. (I realize that this may not be a generally held opinion.) For the record, Janus/Ada gives: In File D:\Testing\Win\console\rep.ada at line 11 -------------- 10: for RECORD_T use record 11: A1 at 0 range 0 .. 0; -- (*) ----------------------------------^ *ERROR* More bits are needed to store all values of the type (6.4.17) [RM 13.5.1(19)] Continue or Abort <^C>? for this example. But that's not all that interesting, because Janus/Ada doesn't support biased representations. Randy.