Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Geert,

On 11/14/21 16:32, Geert Uytterhoeven wrote:
Hi Alejandro,

On Sat, Nov 13, 2021 at 8:56 PM Alejandro Colomar (man-pages)
<alx.manpages@xxxxxxxxx> wrote:
On 11/13/21 14:02, Mickaël Salaün wrote:

ISO C specifies that for the following code:

      enum foo {BAR};

      enum foo foobar;

typeof(foo)    shall be int
typeof(foobar) is implementation-defined

I tested with some version of GCC (from 4.9 to 11) and clang (10 and 11)
with different optimizations and the related sizes are at least the same
as for the int type.

GCC has -fshort-enums to make enum types be as short as possible.  I
expected -Os to turn this on, since it saves space, but it doesn't.

Changing optimization level must not change the ABI, else debugging
would become even more of a nightmare.

I agree, but if you invoke implementation-defined,
then it's not (only) the compiler's fault.

Instead of not allowing GCC to enable -fshort-enums ever,
one can write ISO C-complying code in the parts that
will be exposed as an interface,
by just using int.

That allows using -fshort-enums
for whatever reasons it might be good.

Not saying that the kernel wants to enable it,
but it costs nothing to write non-implementation-defined code
that doesn't forbid it.

It's comparable to passing a struct (not a pointer to it)
to a function.
If you change the size of the struct,
you screw the interface.
Better pass pointers, or standard types.


Alejandro Colomar
Linux man-pages comaintainer;

[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux