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

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

[Geert Uytterhoeven]

	Hi Jori,

> 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@sirena.org.uk/
> 
> Assisted-by: Claude:Opus 4.8
> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>

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?

	#define O_ACCMODE	3U
	#define O_RDONLY	0
	#define O_WRONLY	(1U << 0)
	#define O_RDWR		(1U << 1)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[Jori Koolstra]

Dag Geert,

> Op 16-06-2026 12:22 CEST schreef Geert Uytterhoeven <geert+renesas@glider.be>:
> 
>  
> Hi Jori,
> 
> > 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@sirena.org.uk/
> > 
> > Assisted-by: Claude:Opus 4.8
> > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> 
> 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"

> 
> 	#define O_ACCMODE	3U
> 	#define O_RDONLY	0
> 	#define O_WRONLY	(1U << 0)
> 	#define O_RDWR		(1U << 1)
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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

Groet,
Jori.

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

[David Laight]

On Tue, 16 Jun 2026 12:22:50 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:

> 	Hi Jori,
> 
> > 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@sirena.org.uk/
> > 
> > Assisted-by: Claude:Opus 4.8
> > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>  
> 
> 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)  

I'm not 100% that changing these uapi constants might not generate compile
error for userspace that has duplicate definitions that are currently fine
because the definitions exactly match.

	David

> 
> And suddenly all these constants became signed? Can't that cause subtle
> issues, especially for uapi headers?
> 
> 	#define O_ACCMODE	3U
> 	#define O_RDONLY	0
> 	#define O_WRONLY	(1U << 0)
> 	#define O_RDWR		(1U << 1)
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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
> 

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@xs4all.nl> wrote:
> > Op 16-06-2026 12:22 CEST schreef Geert Uytterhoeven <geert+renesas@glider.be>:
> > > 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@sirena.org.uk/
> > >
> > > Assisted-by: Claude:Opus 4.8
> > > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> >
> > 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@mail.gmail.com

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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