I found a user comment on an MDSN Windows API reference page (Which I've since lost, but I think it was somewhere in the Registry section.) that claims that the Unicode-taking functions in the Windows API (or at least some of them) require the unicode strings to be aligned on a two-byte boundary, otherwise they might not work.

Do D's wstrings (in both D1 and D2) always follow this two-byte alignment (provided that you're not doing any packed-alignment structs, or cast-trickery), or is it something that we need to manually check?

Maybe they mean UCS-2? I know that for example Charles Petzold's Programming Windows book assumes that UTF16 characters are *always* 2 bytes wide. So maybe that has something to do with that alignment requirement.

On Thu, 02 Jun 2011 16:53:12 -0400, Nick Sabalausky <a@a.a> wrote:

> I found a user comment on an MDSN Windows API reference page (Which I've
> since lost, but I think it was somewhere in the Registry section.) that
> claims that the Unicode-taking functions in the Windows API (or at least
> some of them) require the unicode strings to be aligned on a two-byte
> boundary, otherwise they might not work.
>
> Do D's wstrings (in both D1 and D2) always follow this two-byte alignment
> (provided that you're not doing any packed-alignment structs, or
> cast-trickery), or is it something that we need to manually check?

Easy enough to test:

steves@steve-laptop:~/testd$ cat testalign.d
struct Foo
{
    ubyte pad;
    wchar wc;
}

pragma(msg, Foo.wc.offsetof.stringof);

struct Foo2
{
    ubyte pad;
    dchar dc;
}

pragma(msg, Foo2.dc.offsetof.stringof);
steves@steve-laptop:~/testd$ ~/dmd-2.053/linux/bin32/dmd -c testalign.d
2u
4u

So I'd say it does align to 2-byte boundaries (and dchar to 4-byte).  I can't think of a situation where the compiler would break this rule, except for manually overridden (as you mentioned).

Note that all dynamic heap allocations are 16-byte aligned.

-Steve

Btw there's .alignof for these things, which will return 2 bytes.