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-Received: by 10.66.119.174 with SMTP id kv14mr24774677pab.21.1428420483046; Tue, 07 Apr 2015 08:28:03 -0700 (PDT) X-Received: by 10.140.89.116 with SMTP id u107mr267264qgd.18.1428420482780; Tue, 07 Apr 2015 08:28:02 -0700 (PDT) Path: border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!m20no1539790iga.0!news-out.google.com!k20ni23qgd.0!nntp.google.com!j5no154766qga.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 7 Apr 2015 08:28:02 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=75.99.9.146; posting-account=s89PEgoAAABHs2ETFyOrCeTQVQJAfzKq NNTP-Posting-Host: 75.99.9.146 References: <0817bf94-0550-40c4-ba5f-f2ecd6383dbb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: GNAT "alignment value must be positive" From: marciant@earthlink.net Injection-Date: Tue, 07 Apr 2015 15:28:02 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:192757 Date: 2015-04-07T08:28:02-07:00 List-Id: On Monday, April 6, 2015 at 4:48:18 PM UTC-4, Shark8 wrote: > It's because "alignment 0" corresponds to an internal divide-by-zero erro= r. > The LRM (13.4) gives the definition of the alignment portion of record-sp= ecification as: >=20 > alignment_clause ::=3D at mod static_simple_expression; >=20 > So, "mod 0" is obviously erroneous in that case... I'm not sure that it is obvious in that case: "at mod" is just the syntax. I do not think that it means that the compiler is required to evaluate "mod 0". By the way, Object Ada 7.2.x (Ada 95) has accepted alignment 0 for all of the record types that have it. Also, having read your reply (thanks) I realize that I should have included more information in my original post: Ada95 mode is being used and the alignment clause is for a record type. > however, that is the special case of records; in-general what we want is = found in 13.3 which says, in part: >=20 > 22/2 For a prefix X that denotes an object:=20 > 23/2 X'Alignment > The value of this attribute is of type universal_integer, and nonne= gative; zero means that the object is not necessarily aligned on a storage = element boundary. If X'Alignment is not zero, then X is aligned on a storag= e unit boundary and X'Address is an integral multiple of X'Alignment (that = is, the Address modulo the Alignment is zero). >=20 > So, here the 0-alignment means that there is no imposed alignment WRT sto= rage-element boundaries. That is what was desired/expected for all objects or record components of t= he types in question. >=20 > ----------- >=20 > All that said, it could be a bug where GNAT treats an aspect differently = than the corresponding representation-clause/pragma.