Re: GNAT "alignment value must be positive"

[marciant@earthlink.net]

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 error.
> The LRM (13.4) gives the definition of the alignment portion of record-specification as:
> 
>       alignment_clause ::= at mod static_simple_expression;
> 
> 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:
> 
> 22/2  For a prefix X that denotes an object: 
> 23/2  X'Alignment
>       The value of this attribute is of type universal_integer, and nonnegative; 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 storage unit boundary and X'Address is an integral multiple of X'Alignment (that is, the Address modulo the Alignment is zero).
> 
> So, here the 0-alignment means that there is no imposed alignment WRT storage-element boundaries.

That is what was desired/expected for all objects or record components of the types in question.

> 
> -----------
> 
> All that said, it could be a bug where GNAT treats an aspect differently than the corresponding representation-clause/pragma.