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,fd173879a595bde X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc01.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Anonymous Coward Subject: ADA compilers can reject types arbitrarily? References: Message-Id: User-Agent: slrn/0.9.7.4 (Linux) Date: Tue, 15 Nov 2005 01:16:00 GMT NNTP-Posting-Host: 141.149.78.234 X-Complaints-To: abuse@verizon.net X-Trace: trnddc01 1132017360 141.149.78.234 (Mon, 14 Nov 2005 20:16:00 EST) NNTP-Posting-Date: Mon, 14 Nov 2005 20:16:00 EST Xref: g2news1.google.com comp.lang.ada:6387 Date: 2005-11-15T01:16:00+00:00 List-Id: In article , Robert A Duff wrote: > > But surely it makes no sense for the size of an object to always be > the same as the type's size. Boolean'Size = 1, but you want to > allocate Boolean variables in 32-bit registers, quite often. Ah, yes.. I had forgotten that a types size is the same as the value size, since I was dealing with records. It didn't occur to me that record type size specs should really be treated the same as they would be w/ integers; so that makes sense. Considering type sizes are really value sizes, it's more clear to me now why T'size would only specify a minimum. I assume I can expect an O'size spec to be absolute (O being an object). I'm going to backpeddle on how I write interfacing records now. I've rep spec'd the layout of record types (even when the default layout matches) in order to freeze the layout, in case later on the ADA compiler changes. Then I wrote size specs for those records to cause a compile time error if the operational spec grows independant of the rep spec. But since I technically cannot count on the size spec of a record type to be an upper limit, I must apply a size spec to at least one object of the rep spec'd type. That's pretty ugly, considering objects aren't always instantiated in the package of the type definition. So then I might be tempted to create dummy objects for the purpose of protecting against partial rep specs. It's really tempting to scrap the whole idea of writing correct ADA code, in favor of compiler dependant but readable code. > Jeff answered this. By "minumim", I meant that _if_ the compiler > accepts the rep clause, it must allocate at least that many bits for > objects. But "for T'Size use 0;" is still illegal for most types. No way! So an ADA compiler can arbitrarily decide whether to accept a rep spec? From the ARM, you seem to be correct: 13.1 (13): A representation or operational item that is not supported by the implementation is illegal, or raises an exception at run time. Amazing. So an ADA compiler can even reject an operational spec, and still be considered an ADA compiler. ie. an ADA compiler can reject: type my_record is record my_integer : integer; end record; I think that is gives way too much freedom to the compiler. Technically any ADA compiler can reject my composit types, and I have no expectation that my code will run. I'm blown away by this. Even worse, the compiler doesn't have to reject the types at compile time -- it can wait until run time to raise exceptions. What am I missing?