From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Richard <richiezid@arcor.de>
Cc: debian-68k@lists.debian.org,
James Le Cuirot <chewi@aura-online.co.uk>,
Finn Thain <fthain@linux-m68k.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
libc-help@sourceware.org,
linux-m68k <linux-m68k@vger.kernel.org>
Subject: Re: Tuple and changes for m68k with -malign-int
Date: Mon, 28 Aug 2023 13:40:39 +0200 [thread overview]
Message-ID: <CAMuHMdUbqEynODaEsmNPO_7Os9hw-jsAr0FrF4E7e=OePgvJ3Q@mail.gmail.com> (raw)
In-Reply-To: <BEE12C98-6C32-4ECE-888F-EC01D4E5BCFD@arcor.de>
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
next prev parent reply other threads:[~2023-08-28 11:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-26 8:53 James Le Cuirot
2023-08-26 10:51 ` John Paul Adrian Glaubitz
2023-08-26 19:24 ` Richard
2023-08-26 20:43 ` James Le Cuirot
2023-08-28 6:54 ` Geert Uytterhoeven
2023-08-28 10:57 ` John Paul Adrian Glaubitz
2023-08-28 12:11 ` Richard
2023-08-28 12:22 ` Geert Uytterhoeven
2023-08-28 12:46 ` John Paul Adrian Glaubitz
2023-08-27 0:46 ` Finn Thain
2023-08-27 9:20 ` James Le Cuirot
2023-08-27 11:27 ` Richard
2023-08-28 7:00 ` Geert Uytterhoeven
2023-08-28 11:26 ` Richard
2023-08-28 11:40 ` Geert Uytterhoeven [this message]
2023-08-28 20:16 ` Richard
2023-08-29 6:52 ` Geert Uytterhoeven
2023-08-28 6:56 ` Geert Uytterhoeven
2023-08-28 11:13 ` John Paul Adrian Glaubitz
2023-08-29 1:12 ` Finn Thain
2023-08-28 11:10 ` John Paul Adrian Glaubitz
2023-08-28 12:44 ` Adhemerval Zanella Netto
2023-08-28 12:50 ` John Paul Adrian Glaubitz
2023-08-28 13:17 ` Andreas Schwab
2023-08-29 10:51 ` John Paul Adrian Glaubitz
2023-08-29 15:27 ` Geert Uytterhoeven
2023-08-28 13:29 ` James Le Cuirot
2023-08-29 10:54 ` John Paul Adrian Glaubitz
2023-08-29 21:53 ` Karoly Balogh
2023-08-30 1:33 ` Jeffrey Walton
2023-08-29 1:14 ` Finn Thain
2023-08-29 8:52 ` Eero Tamminen
2023-08-28 5:15 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdUbqEynODaEsmNPO_7Os9hw-jsAr0FrF4E7e=OePgvJ3Q@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=chewi@aura-online.co.uk \
--cc=debian-68k@lists.debian.org \
--cc=fthain@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=libc-help@sourceware.org \
--cc=linux-m68k@vger.kernel.org \
--cc=richiezid@arcor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).