public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Richard <richiezid@arcor.de>
To: debian-68k@lists.debian.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	James Le Cuirot <chewi@aura-online.co.uk>
Cc: Finn Thain <fthain@linux-m68k.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	libc-help@sourceware.org,
	debian-68k <debian-68k@lists.debian.org>,
	linux-m68k <linux-m68k@vger.kernel.org>
Subject: Re: Tuple and changes for m68k with -malign-int
Date: Mon, 28 Aug 2023 11:26:58 +0000	[thread overview]
Message-ID: <BEE12C98-6C32-4ECE-888F-EC01D4E5BCFD@arcor.de> (raw)
In-Reply-To: <CAMuHMdUV0oM=zp6dG0KNbPJz2m7KBhynHa=ENUJmfh=u3gisbg@mail.gmail.com>




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.

Richard

  reply	other threads:[~2023-08-28 11:27 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 [this message]
2023-08-28 11:40           ` Geert Uytterhoeven
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=BEE12C98-6C32-4ECE-888F-EC01D4E5BCFD@arcor.de \
    --to=richiezid@arcor.de \
    --cc=chewi@aura-online.co.uk \
    --cc=debian-68k@lists.debian.org \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=libc-help@sourceware.org \
    --cc=linux-m68k@vger.kernel.org \
    /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).