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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT "alignment value must be positive" Date: Fri, 10 Apr 2015 16:18:10 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1428700691 8426 24.196.82.226 (10 Apr 2015 21:18:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 10 Apr 2015 21:18:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:25511 Date: 2015-04-10T16:18:10-05:00 List-Id: wrote in message news:ae527812-cf69-4141-8cdb-7d44f0be19a3@googlegroups.com... On Thursday, April 9, 2015 at 8:21:55 PM UTC-4, Randy Brukardt wrote: ... ... >> > - "zero means that the object is not necessarily aligned on a storage >> > element >> > boundary."? >> >> That's talking about the value of X'Alignment, when it is *read*, not so >> much when it is specified. (This is 13.3(23/2)). > >But if the "natural"/"default" alignment that an implementation would use >when it >places an object of some type is - lets say 2, what about the case that a >user >program does unchecked conversion on a sequence of bits to a record type >that ends up making the alignment of some of the records components not >have >the default alignment (not 2 in the example - infact not even alignment 1). >I thought that this was a case where the user should specify alignment 0 >for the >component's type and that without doing that, improper reading of the >component >by the program might be the result, due to the compiler having assumed that >the >component/"object" had its default alignment. That's clearly target dependent. On the x86 where I've done most of my work, alignment has no impact on the code (it does have an impact on performance). Everything is at least byte-aligned (objects are copied to make that so for parameter passing, and of course, unaligned by-reference objects aren't allowed), and the machine has no problem with unaligned accesses. (Well, there are some of the rarely-used vector operations that only work on aligned data; that's one reason why we don't use them. :-) There certainly are targets that differ; at least in theory. That's not surprising, ultimately Chapter 13 is all about target-dependent stuff anyway. But even then, I'd expect (in your example) the Unchecked_Conversion to make a copy so the proper alignment is maintained. It's a function after all, the semantics are that of a copy (there's a permission to make it by-reference, but an implementor would be silly to use such a permission if it caused later code problems). Randy.