Re: GNAT "alignment value must be positive"

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mg18lb$r36$1@dont-email.me...
...
> However, note also the additional requirements for a composite type: "If 
> an
> Alignment is specified for a composite subtype or object, this Alignment 
> shall
> be equal to the least common multiple of any specified Alignments of the
> subcomponent subtypes, or an integer multiple thereof." If your record has
> components with specified non-zero alignment, then the alignment of the 
> record
> must be non-zero.

This requirement is nonsense and was deleted from the language for Ada 2005. 
And few compilers ever enforced it (Janus/Ada did, but GNAT did not, so far 
as I know). It probably would have been deleted sooner had I asked about it 
rather than just implementing it as the rule. The intent is that any 
"inherited" properties can always be overridden by a explicitly specified 
property.

...
> So zero should be allowed in this obsolescent form as well.
>
> If GNAT is rejecting zero when allowed by these rules then it would seem 
> to be a
> compiler error.

I don't think Janus/Ada allows specifying zero, but that makes some sense as 
no stand-alone object could ever be allocated at a non-byte-aligned address. 
Nor would that ever happen for a component in the absence of some other 
representation item. So there is nothing that could actually be aligned as 
"zero". Perhaps GNAT is making the same assumption.

0 is defined as a possible alignment so that the alignment of a bit-mapped 
component is meaningful (we can't have 'Alignment not meaning anything). But 
I don't know of any reason to specify the alignment as zero, everything is 
always byte allocated by default. There might be some machine on which it 
makes sense to not byte align by default, but I haven't encountered it to 
date.

                                          Randy.