All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <ravi@prevas.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Sterba <dsterba@suse.com>,
	 linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 6.18-rc2
Date: Sun, 19 Oct 2025 23:53:33 +0200	[thread overview]
Message-ID: <87plaieexu.fsf@prevas.dk> (raw)
In-Reply-To: <CAHk-=wiiysgAErOobR02zECiniaM69AacAHjTOSKsv3yDF2R+A@mail.gmail.com> (Linus Torvalds's message of "Thu, 16 Oct 2025 10:58:16 -0700")

On Thu, Oct 16 2025, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 16 Oct 2025 at 10:00, David Sterba <dsterba@suse.com> wrote:
>>
>> - reorder send context structure to avoid -Wflex-array-member-not-at-end
>>   warning
>
> Ok, I took a look because this sounded like a bad bug, but that flex
> array member really isn't a flex array at all.
>
> It's clearly intended to be a fixed-size inline array, just using a
> flex array for syntacting reasons.
>
[...]
>
> Sadly, I can't think of a way to have the compiler just calculate the
> right size at structure definition time without just having to repeat
> the whole structure definition twice.
>
> So that flex array may be the best approach even if it has these downsides.
>
> Does anybody know of some C language trick to get the remaining
> padding size without repeating the struct definition?
>
> "offsetof()" sadly does not work until the structure has been fully
> defined, so you can't use the "obvious" trick
>
>     char buffer[256 - offsetof(struct .., buffer)];
>

I think this has come up before [*]. Doesn't -fms-extensions allow one
to do

struct __fs_path {
	char *start;
	char *end;
        ...
};
static_assert(sizeof(struct __fs_path) < 256);
struct fs_path {
	struct __fs_path;
	char inline_buf[256 - sizeof(struct __fs_path)];
};

and access every member of fs_path as one used to? With the bonus that
it's a real array with known size.

Rasmus

[*]
https://lore.kernel.org/lkml/CAHk-=wh6Ra8=dBUTo1vKT5Wao1hFq3+2x1mDwmBcVx2Ahp_rag@mail.gmail.com/

  reply	other threads:[~2025-10-19 21:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 16:59 [GIT PULL] Btrfs fixes for 6.18-rc2 David Sterba
2025-10-16 17:58 ` Linus Torvalds
2025-10-19 21:53   ` Rasmus Villemoes [this message]
2025-10-20  1:17     ` Linus Torvalds
2025-10-22  4:52       ` David Sterba
2025-10-16 18:06 ` pr-tracker-bot

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=87plaieexu.fsf@prevas.dk \
    --to=ravi@prevas.dk \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.