Re: [GIT PULL] bcachefs

Arnaldo Carvalho de Melo
2023-09-06T23:52:25Z

Em Wed, Sep 06, 2023 at 04:34:32PM -0700, Linus Torvalds escreveu:
> On Wed, 6 Sept 2023 at 16:20, David Sterba <dsterba@suse.cz> wrote:
> > I think I've always seen an int for enums, unless it was
> > explicitly narrowed in the structure (:8) or by __packed attribute in
> > the enum definition.

> 'int' is definitely the default (and traditional) behavior.

> But exactly because enums can act very differently depending on
> compiler options (and some of those may have different defaults on
> different architectures), we should never ever have a bare 'enum' as
> part of a structure in any UAPI.

> In fact, having an enum as a bitfield is much better for that case.

> Doing a quick grep shows that sadly people haven't realized that.

> Now: using -fshort-enum can break a _lot_ of libraries exactly for
> this kind of reason, so the kernel isn't unusual, and I don't know of
> anybody who actually uses -fshort-enum. I'm mentioning -fshort-enum
> not because it's likely to be used, but mainly because it's an easy
> way to show some issues.

> You can get very similar issues by just having unusual enum values. Doing
>
> enum mynum { val = 0x80000000 };

> does something special too.

> I leave it to the reader to figure out, but as a hint it's basically
> exactly the same issue as I was trying to show with my crazy
> -fshort-enum example.

Two extra hints:

⬢[acme@toolbox perf-tools-next]$ grep KIND_ENUM64 include/uapi/linux/btf.h
BTF_KIND_ENUM64 = 19, /* Enumeration up to 64-bit values */
/* BTF_KIND_ENUM64 is followed by multiple "struct btf_enum64".
⬢[acme@toolbox perf-tools-next]$

⬢[acme@toolbox perf-tools-next]$ pahole --help |& grep enum
--skip_encoding_btf_enum64 Do not encode ENUM64s in BTF.
⬢[acme@toolbox perf-tools-next]$

:-)

- Arnaldo