Messages in this thread | | | Subject | Re: [patch] fat/msdos/vfat crud removal | From | (Eric W. Biederman) | Date | 12 Jun 2002 00:50:45 -0600 |
| |
Jamie Lokier <lk@tantalophile.demon.co.uk> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |