Thread overview
[Issue 3183] New: Spec of align attribute needs work
Jul 16, 2009
smjg@iname.com
Aug 31, 2009
Walter Bright
Aug 31, 2009
Stewart Gordon
Sep 03, 2009
Walter Bright
July 16, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3183

           Summary: Spec of align attribute needs work
           Product: D
           Version: unspecified
          Platform: All
               URL: http://www.digitalmars.com/d/archives/digitalmars/D/Sp
                    ec_of_align_attribute_is_a_mess_88129.html
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: smjg@iname.com
            Blocks: 677,3118


There are ambiguities and inconsistencies in how the align attribute is described in the D specification.  What follows is a cut-down version of the unanswered post at the given URL, with a few bits thrown in from other posts.

1. Is the whole purpose of it for portability of data or for C ABI compatibility?

ctod.html:
"Clearly, since much of the point to setting alignment is for
portability of data, a portable means of expressing it is necessary."

attribute.html:
"AlignAttribute is meant for C ABI compatiblity [sic], which is not the
same thing as binary compatibility across diverse platforms. For that,
use packed structs:"

2. attribute.html describes align as matching the behaviour of the companion C compiler.  What if there's no companion C compiler, or the companion C compiler doesn't support alignment control at the level it has been used in the D code?

3. I had for ages made out align to be purely about the relative alignment of
members within a struct.  But a discussion at
http://tinyurl.com/nqs2n3#N87948
(that message onwards) got me confused until I realised that people were
interpreting it as absolute alignment.  The spec doesn't clarify one way or the
other.  Which is it meant to be?

4. Following on from point 3, should it apply only to structs as is currently documented?  Or should it work on unions as well?  Even arbitrary variable declarations?

5. And how should the compiler handle it if used where inapplicable?  There are the odd bits in the spec on this, but it wants rethinking.  This is just one case of issue 3118.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 31, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3183


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com




--- Comment #1 from Walter Bright <bugzilla@digitalmars.com>  2009-08-31 02:44:07 PDT ---
1. C ABI compatibility.

2. There's always a companion C compiler, as D relies on the existence of the C runtime library.

3. It's the way the companion C compiler aligns.

4. Unions members are all at offset 0. Unions are aligned according to the alignment of their largest field.

5. It is ignored for non-struct fields.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 31, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3183





--- Comment #2 from Stewart Gordon <smjg@iname.com>  2009-08-31 04:57:28 PDT ---
(In reply to comment #1)
> 2. There's always a companion C compiler, as D relies on the existence of the C runtime library.

So a prerequisite for writing a D compiler from scratch is to write a C compiler first?  Still, that doesn't answer my question beyond the first 7 words.

> 3. It's the way the companion C compiler aligns.

Still, that this may be absolute or relative depending on the companion C compiler ought to be mentioned in the D spec at least to crack down on the user confusion of which I have been a victim.

> 4. Unions members are all at offset 0. Unions are aligned according to the alignment of their largest field.

You mean aligned in a containing struct, or aligned absolutely _if_ the implementation interprets alignment as absolute?  Neither seems to be happening in my test (1.046):

----------
align(1) struct Qwert {
    byte b1;
    align(1) struct {
        byte b2;
        union {
            align (4) struct { int i; }
        }
    }
}

pragma(msg, "Qwert.alignof == " ~ Qwert.alignof.stringof);
pragma(msg, "Qwert.b1.alignof == " ~ Qwert.b1.alignof.stringof);
pragma(msg, "Qwert.b2.alignof == " ~ Qwert.b2.alignof.stringof);
pragma(msg, "Qwert.i.alignof == " ~ Qwert.i.alignof.stringof);
pragma(msg, "Qwert.b1.offsetof == " ~ Qwert.b1.offsetof.stringof);
pragma(msg, "Qwert.b2.offsetof == " ~ Qwert.b2.offsetof.stringof);
pragma(msg, "Qwert.i.offsetof == " ~ Qwert.i.offsetof.stringof);
----------
Qwert.alignof == 1u
Qwert.b1.alignof == 1u
Qwert.b2.alignof == 1u
Qwert.i.alignof == 4u
Qwert.b1.offsetof == 0u
Qwert.b2.offsetof == 1u
Qwert.i.offsetof == 2u
----------

But to both 4 and 5, I said "should", i.e. I was pondering over what's desirable and whether the spec ought to be changed, not what the current spec or behaviour is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 03, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3183


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Walter Bright <bugzilla@digitalmars.com>  2009-09-03 13:26:26 PDT ---
Fixed dmd 1.047 and 2.032

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------