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 ;-)

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

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.

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