Re: [patch] fat/msdos/vfat crud removal

[Eric W. Biederman]

Jamie Lokier <[e-mail]> writes:

> Eric W. Biederman wrote:
> > Actually by now most applications have been fixed and do not use
> > them.  The policy has been in place for several years now.
> 
> I like this policy and understand how to use it, except...
 
First early adopters of any feature have a challenge.  

> Once upon a time I wrote a program which used O_NOFOLLOW, before Glibc
> had support for that flag.
> 
> It had to read the kernel headers, as this macro is an
> architecture-dependent flag, and I did not want to write a program that
> was so non-portable it would only compile on some architectures.
> 
> Even if I'd copied all the definitions for all architectures out of the
> kernel, that wouldn't do: the program wouldn't compile on architectures
> added later, or ones that aren't part of the standard distribution.
> 
> So to keep the program relatively portable, it searched for definitions
> of O_NOFOLLOW in the kernel headers.  (It was a Glibc/kernel conflict
> nightmare).
> 
> Please can you suggest how I should write this sort of code, the next
> time it occurs?

Hmm.  I think I would do:
/* use the standard open includes */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#ifndef O_NOFOLLOW
#ifdef __i386__
#define O_NOFOLLOW  0400000
#else
#error I must have O_NOFOLLOW fix glibc
#endif
#endif

Or if it really didn't matter much:
#ifndef O_NOFOLLOW
#define O_NOFOLLOW 0
#endif

But even beyond that it makes a lot of sense to have autoconf add
a test for O_NOFOLLOW, and do something appropriate if it isn't
defined, or supported.  Otherwise your code gets brittle anyway. 

Where generic API extensions end up in the future is pretty well
defined, so you don't have to guess where libc will put them.

In most cases the kernel header rule only applies to pure linux
specific interfaces where the numbers don't change between
architectures, and to interfaces that are specific to a small subset
of programs, (device specific code like hdparm).   

But even using kernel headers doesn't help on current systems,
as you should have headers that correspond to the version of the
kernel your libc was compiled against.  So if libc didn't support
O_NOFOLLOW it is quite unlikely that user space would in any form.

Eric