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=ham 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!postnews.google.com!i36g2000prf.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Enumeration representation clause surprise. Date: Wed, 11 Jun 2008 12:10:33 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4a84770f-e273-41ad-a8ef-f22a9896b544@i36g2000prf.googlegroups.com> References: <0cbb6daf-01e9-40f5-855c-4f1d45cb0096@m73g2000hsh.googlegroups.com> <87abhs6qyj.fsf@willow.rfc1149.net> <55613982-679e-419d-8656-03b549393289@w4g2000prd.googlegroups.com> <871w346k4j.fsf@willow.rfc1149.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1213211433 30345 127.0.0.1 (11 Jun 2008 19:10:33 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 11 Jun 2008 19:10:33 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i36g2000prf.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:657 Date: 2008-06-11T12:10:33-07:00 List-Id: On Jun 11, 8:56 am, Samuel Tardieu wrote: > Adam> This seems odd to me. Having GNAT select a biased component in > Adam> Christoph's example makes some sense, since a compiler can choose any > Adam> representation it likes. But in Markus' case, he specifically asked > Adam> for a certain representation for the enumeration types---should GNAT > Adam> take it upon itself to change that, and display a warning that doesn't > Adam> make it clear that it's disrespecting his request to have the > Adam> enumeration represented a certain way? > Adam> > Adam> I dunno... maybe this would be acceptable to some, and apparently > Adam> Markus thinks it's OK, but ... it's just not what I would expect ... > Adam> I guess it's a subjective thing. > > I would prefer an error indeed, Then there's no reason it couldn't generate one... implementations are allowed to reject any representation clauses (including component clauses) that they don't support, and there's nothing in the Implementation Advice of 13.5.1 that would "require" (or advise) an implementation to support this. (In fact, there's nothing that would "require" an implementation to implement biased values as in Christopher's example.) > but I can't seem to find a clause in > chapter 13 which says that in records with representation clauses the > representation given for objects when created independently the > enumeration representation clause must be honored. Technically, that may be correct, although technically it may be that the RM doesn't require the specified representation to be honored for *any* objects, stand-alone or component. At least I couldn't find anything specific, unless this is "generally implied" by the whole chapter or by 13.1. It may be that it's legal for an implementation to accept an enumeration representation clause and then never apply it. But components are objects, and I don't see anything in 13.4 that would apply unequally to component objects vis-a-vis stand-alone objects. Anyway, since it's clearly legal for an implementation to reject Markus' code, I think it should. Although it may be *possible* that an implementation *could* find a way to obey the record rep clause by using a different representation for the enumeration component (if this is indeed legal), there's a 0% chance that any such usage would be what the programmer intended, and a 100% chance that a usage like this would indicate an error on the programmer's part. -- Adam