Re: [GIT PULL] bcachefs

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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