Em Wed, Sep 06, 2023 at 04:34:32PM -0700, Linus Torvalds escreveu:
> On Wed, 6 Sept 2023 at 16:20, David Sterba <dsterba@xxxxxxx> 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
