On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> >https://gcc.gnu.org/wiki/RustFrontEnd
>
> That’s assuming it can build the same stuff the same way so it can be
> used in packaging.
>
Not an assumption. I simply pointed out an opportunity for collaboration,
because I see the primary problem facing the m68k port is a lack of
resources.
> >I expect alignment assumptions like that will end up putting more
> >platforms in the same predicament in future.
>
> No, all the other platforms use natural alignment.
>
> >"Natural" alignment is meaningless in the context of portable data
> >structures, as they exist without reference to any particular integer
>
> Yeah, but in practice, all we have is ILP32 and LP64;
... for now.
> the Windows® world has LLP64 in addition. And natural alignment just
> means that all the data types’ alignment is their size. (Which kind of
> makes sense, so you can read them without getting an unalignment trap on
> SPARC or so.)
>
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
> >Q. What is the size of this struct, assuming baa.b is naturally aligned?
> >
> >struct baa {
> > int a;
> > long long b;
> >};
>
> For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
So natural alignment is portable if you first assume a data model. But the
struct definition itself is not portable, since it doesn't specify a data
model.
> More importantly, and relevant for Qt, struct baa is also 8-byte
> aligned...
>
If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.
