Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

I really think you are making this unnecessarily complex here because
I can't follow most of what you are writing.

    > Now consider a function that takes an object of type T that is *not* part
    > of the current compilation.  When generating code to dereference P, it is
    > not allowed to assume that the alignment of the object pointed to by P
    > is *more* than four bytes.

    This I understood already.  I think everyone sees this.

Actually not, because that's the key point in below:

    <lightbulb>
      Oh, I see why you mustn't increase alignment on types!  Thanks!
    </lightbulb>

If the above were obvious, so would this have been.

    > So doing so would be conforming to the standard.

    Somebody brought up an example where that might not be reasonable:
    multiple object in a special linker section, and the programmer
    expects them to be laid out as if in an array.  

Yes, but it's important to distinguish between what's "conforming" and
what's "reasonable".  As Robert Dewar points out, it's comforming to
implement multiplication as a loop over addition, but not reasonable.
But you can't try to determine what's "reasonable" by consulting a
standards document.

    Ok, now I agree it is practical to want to reduce an object's
    alignment for storage purposes.  (But isn't that why we have
    __attribute__((packed))?)

Yes.

    The essential quirk is this: whenever you take the address of an
    object, if you have specified the object's alignment and it is less
    than that of the original type, 

That should be an error.