public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
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

  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).