sys/mount.h vs fcntl.h

[DJ Delorie]

Florian Weimer <fweimer@redhat.com> writes:
>>> #ifndef O_CLOEXEC
>>> # include <bits/cloexec.h>
>>> # define O_CLOEXEC __O_CLOEXEC
>>> #endif
>>> #define OPEN_TREE_CLOEXEC O_CLOEXEC
>>
>> I will note that if we do this, we're back to "polluting" the namespace,
>> and will have to remove that check from tst-open-tree-cloexec.c ;-)
>
> <sys/mount.h> is not a standards-defined header, so namespace management
> is less of a concern.

Agreed.  Just noting.

>> tst-mount.c is changed to include <fcntl.h>, no big deal.
>
> Do you mean <linux/fcntl.h>?

No, the test includes <fcntl.h> as the man page documents.

>> tst-fcntl-cloexec.c and tst-open-tree-cloexec.c test to ensure that
>> fcntl.h and sys/mount.h can be used independently and still provide the
>> right defines and values.  Which means they can't include other headers,
>> and must intrinsically "know" the right values for all platforms.
>
> The right way to check for correct values would be a Python test.  Or
> the test I suggested above.

Why python, when we can do it in C?  We need to test the "independend
inclusion" part anyway...

> None of the tests appear to check simultaneous includes that were
> reported as the original bug, though.  Maybe we should test for that,
> and not use some check on O_ macros as a proxy?

I could add another test for that specific case, true.

>> If the kernel headers and glibc headers don't agree, wouldn't gcc give
>> warnings (errors) when both are included anyway?  If so, as long as we
>> do this at least once somewhere in our build tree, we're already
>> covering it.
>
> If we ever include them both, yes.  We do not currently include
> <linux/fcntl.h> at all.

Ah.

> Your patch as posted doesn't change that.

Correct.  Comparing linux headers to glibc headers is IMHO outside the
scope of this change.