mbox series

[RFC,0/1] Attempt to detect missing fcntl argument at compile time

Message ID 20230519213059.3812385-1-bugaevc@gmail.com
Headers show
Series Attempt to detect missing fcntl argument at compile time | expand

Message

Sergey Bugaev May 19, 2023, 9:30 p.m. UTC 
Hello,

here goes another attempt to step out of the comfort zone into the
"I don't know what I'm doing" zone -- this time with fcntl and inline
wrappers and FORTIFY_SOURCE.

It *appears* to build and work and not break anything; I've tried
x86_64-gnu, i686-gnu, i686-linux-gnu, and x86_64-linux-gnu. On
i686-linux-gnu I've tried defining various macros, such as
_LARGEFILE64_SOURCE and _FILE_OFFSET_BITS (to 32 or 64). Things *appear*
to work just as I expect them to; the build breaks when I try to compile
an fcntl () without a required argument, and I do get an error at
runtime as expected too. All the right symbols appear to get referenced
in all configurations, too.

Still, I'm not very sure I've handled all the possible configurations
correctly.

The reasoning for __fcntl_cmd_needs_arg () being a function and not a
macro is that the definition needs to use multiple #ifdefs and that
would be awkward with a macro. Hopefully I have handled various
combinations of fcntl commands being defined / not defined correctly
too, so the user never gets a compilation error just because
__fcntl_cmd_needs_arg () wants to handle some command that is not
defined in their configuration. When building fcntl{,64}_2.c, all the
commands (that are supported on this kernel, i.e. not Linux specifics
on the Hurd) should be defined, and so the runtime calls to
__fcntl_cmd_needs_arg () get this full version. When building user code,
some commands may not be defined (depending on enabled feature macros),
but then the expectation is the user cannot use those commands they do
not have enabled.

Sergey