Re: Tuple and changes for m68k with -malign-int
Geert Uytterhoeven <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.user,gmane.linux.debian.ports.68k,gmane.linux.ports.m68k |
|---|---|
| Message-ID | <CAMuHMdUbqEynODaEsmNPO_7Os9hw-jsAr0FrF4E7e=OePgvJ3Q@mail.gmail.com> |
Hi Richard, On Mon, Aug 28, 2023 at 1:27 PM Richard <[email protected]> wrote: > On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <[email protected]> wrote: > >On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot > ><chewi-Yn+4UywRBy5n8C+U7lyxXlpr/1R2p/[email protected]> 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 -- [email protected] 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