[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tuple and changes for m68k with -malign-int



Hi Richard,

On Mon, Aug 28, 2023 at 1:27 PM Richard <richiezid@arcor.de> wrote:
> On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
> ><chewi@aura-online.co.uk> wrote:
> >> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> >> > Moreover, why is it that only a few developers have a problem with making
> >> > explicit their decisions regarding alignment of shorts? What actual pain
> >> > does it cause them to accept a patch to make their struct layouts plain?
> >>
> >> Some projects do accept patches. Yann Collet was even kind enough to fix this
> >> in zstd themselves. On the other hand, we have had to fight to stop Python
> >> from dropping m68k support entirely. The real problem is the effort required
> >> to produce these patches. I haven't been able to wrap my head around this so
> >> far, but I would still like to learn. I could see myself eventually fixing
> >> mold, but LLVM feels like a very tall order.
> >
> >Perhaps we need a new compiler warning: "hole in structure due to
> >non-natural alignment, please consider adding explicit padding"?
>
> Sounds reasonable but I am afraid in 99% of cases this would be completely irrelevant and not break anything so the acceptance would be pretty low.
>
> The problem arises only when people start doing "strange" things with such structs. Can we define strange things in a better way? It appears to me all modern c standards somewhat lack an attribute to mark a struct as being "special use" and thus emit more warnings and avoid some kinds of trickery.

Do you consider

    struct foo {
            short x;
            int y;
    } bar;

a "strange" thing? In se it's not strange.

Unless someone starts doing:

     assert(sizeof(struct foo) == 8);

or:

    write(fd, &bar, sizeof(bar));

and expects this to be portable/interoperable (ignoring endianness
for now).

IIRC, there are similar issues with the alignment of long long and double
on some 32-bit platforms, where they would not be aligned naturally.

In Linux userspace APIs, we always[*] use natural alignment and
explicit padding.

[*] try to.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


Reply to: