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

[David Laight <david.laight.linux@gmail.com>]

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
>