Re: [PATCH] vfs: uapi: retire octal and hex numbers in favor of (1 << n) for O_ flags

[Geert Uytterhoeven]

Hoi Jori,

On Tue, 16 Jun 2026 at 16:51, Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> > Op 16-06-2026 12:22 CEST schreef Geert Uytterhoeven <geert+renesas@xxxxxxxxx>:
> > > A recent build failure[1] exposed the diffculty of working with the
> > > current octal and hex definitions of O_ flags when trying to find a gap
> > > for a new flag. This difficulty is compounded by the fact that O_ flags
> > > may have architectural specific values.
> > >
> > > Replace the hex/octal #defines, which are hard to parse when looking for
> > > free bits, with explicit bit shifts like (1 << 11). Also, add comments
> > > that identify which architectures redefine some of the seemingly free
> > > ("cursed") bits in uapi/asm-generic/fcntl.h. These should not be used to
> > > define new O_ flags (for now, at least).
> > >
> > > The translastion was done with Claude Opus 4.8, and verified with a
> > > (non-AI) gawk script. The accounting of which architectures claim
> > > which bit-gaps in uapi/asm-generic/fcntl.h is also done by hand.
> > >
> > > [1]: https://lore.kernel.org/all/agruPPybCx8q2XcJ@xxxxxxxxxxxxx/
> > >
> > > Assisted-by: Claude:Opus 4.8
> > > Signed-off-by: Jori Koolstra <jkoolstra@xxxxxxxxx>
> >
> > Thanks for your patch, which is now commit 0da79c259ad0554b ("vfs:
> > uapi: retire octal and hex numbers in favor of (1 << n) for O_
> > flags").
> >
> > > --- a/include/uapi/asm-generic/fcntl.h
> > > +++ b/include/uapi/asm-generic/fcntl.h
> > > @@ -15,51 +15,55 @@
> > >   * When introducing new O_* bits, please check its uniqueness in fcntl_init().
> > >   */
> > >
> > > -#define O_ACCMODE  00000003
> > > -#define O_RDONLY   00000000
> > > -#define O_WRONLY   00000001
> > > -#define O_RDWR             00000002
> > > +#define O_ACCMODE  3
> > > +#define O_RDONLY   0
> > > +#define O_WRONLY   (1 << 0)
> > > +#define O_RDWR             (1 << 1)
> >
> > And suddenly all these constants became signed? Can't that cause subtle
> > issues, especially for uapi headers?
>
> Isn't 00000003 already singed? I am by no means a C language expert, but what
> I can find in the C99 standard is:
>
>     The type of an integer constant is the first of the corresponding list in which
>     its value can be represented.
>
> and for octal and hex constants this list starts with "int"

Sorry, I indeed misremembered[1] that hexadecimal and octal constants
are always unsigned.  Instead, they are only unsigned if they no longer
fit in the corresponding signed type.

So "(1 << n)" has the same signedness as the old octal constants,
unless n is 31 (shifting into the sign bit), or n > 31 (needs an
ULL-suffix for 64-bit).  But your patch has no such cases.

[1] https://lore.kernel.org/all/CAHk-=wgcv_YewP0rgwR1+gj3YF-7Jz8WPVzDgndx0DVMVKzV=Q@xxxxxxxxxxxxxx

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds