sys/mount.h vs fcntl.h

[Florian Weimer]

* DJ Delorie:

> Florian Weimer <fweimer@redhat.com> writes:
>> I suggest this instead:
>>
>> #include <bits/cloexec.h>
>> #define O_CLOEXEC __O_CLOEXEC
>> #define OPEN_TREE_CLOEXEC O_CLOEXEC
>>
>> So it's identical to the kernel macro definition and no #undef is
>> needed.
>
> Do we need an #undef before that first #define, in case it's already
> defined?  I assume no, since the definitions would be identical (the
> user can include fcntl.h before sys/mount.h), but in case they
> aren't (because future kernel header conflicts).

Hmm, good point, it should be:

#ifndef O_CLOEXEC
# include <bits/cloexec.h>
# define O_CLOEXEC __O_CLOEXEC
#endif
#define OPEN_TREE_CLOEXEC O_CLOEXEC

>> > +/* Both fcntl.h and sys/mount.h include APIs that need O_CLOEXEC.
>> > +
>> > +   So, there's an arch-specific header for this constant, just for
>> > +   this purpose.  We test that it is defined correctly here, and that
>> > +   fcntl.h can use it.  */
>> 
>> You can include both <bits/cloexec.h> and the kernel header
>> <linux/fcntl.h> and use static_assert.
>
> 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.

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

Thanks,
Florian