sys/mount.h vs fcntl.h

[Florian Weimer]

* 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.  I think we could define all the O_ constants
here, except that your experiments suggest that this is too much of a
hassle.

>>> That's not what I was testing.  The test specifically tests user-level
>>> includes to make sure all the changes I made result in a workable
>>> solution.
>>
>> Did I comment on the wrong test?
>>
>> I really think we should avoid the #ifdef __alpha__ business, and
>> including <linux/fcntl.h> would allow us to do that.
>
> There are three tests.
>
> tst-mount.c is changed to include <fcntl.h>, no big deal.

Do you mean <linux/fcntl.h>?

> 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.

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?

>>>> Or write a tst-fcntl-consts.py test that checks all constants.  This
>>>> would completely break the build if there's an inconsistency.
>>>
>>> I don't think that would be useful for most constants.  It would just
>>> mean "any change has to be made twice" without solving any problems.
>>
>> It has regular expressions and whatnot.  It gets the expected values
>> from kernel headers.
>
> 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.  Your patch as posted doesn't change that.

Thanks,
Florian