[PATCH v3 0/5] fcntl fortification

[Sergey Bugaev]

On Tue, Jun 20, 2023 at 12:41 PM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
> I don't think CPU architecture plays a role here either.  My guess (didn't verify) is that the difference comes from GCC version and its default C standard.

But the C standard is being explicitly set in these tests (those
-std=c89 flags), no?

> In our case we are running CI in latest Ubuntu LTS (22.04 at the moment), which has GCC 11.
>
> What environment did you test this in?

I have GCC 13.1 and Clang 16.0 targeting {x86_64,i686}-linux-gnu, GCC
12.2 targeting i686-gnu, and GCC master targeting x86_64-gnu. I have
only run the full testsuite on x86_64-linux-gnu (and it does pass,
including all the check-installed-headers tests); for the other
variants I've only checked debug/tst-fortify (which also tries to
compile the header in various configurations) and tried to build
sample code against the installed headers manually (but have not
checked different C standards and _XXXX_SOURCE definitions while doing
that). I have also done some checks on Compiler Explorer, and indeed I
can reproduce F_DUPFD_CLOEXEC being unavailable with -std=c89 (or any
non-GNU C, e.g. -std=c11) there -- but that happens when targeting
x86_64 too.

...Having written the above, I went and re-ran the test suite, and
traced which files GCC opens, and it does not even look at fcntl3.h
when running check-installed-headers! That explains it, the CI must
have _FORTIFY_SOURCE set in the CFLAGS for glibc itself, but I don't,
and Adhemerval probably doesn't either. With _FORTIFY_SOURCE manually
added, I can reproduce the exact test failure on my setup too.

Thanks!

Sergey