Re: argh!

[Zack Weinberg <zack@rabi.columbia.edu>]

On 19 Oct 1998 17:44:54 -0700, Ulrich Drepper wrote:
>Zack Weinberg <zack@rabi.columbia.edu> writes:
>
>> You can throw out tryopen_append_slash, but I think looking for
>> O_DIRECTORY at runtime is a good idea.  Calling fstat doesn't add much
>> overhead but calling stat does
>
>Hum, can anything bad happen while doing the test?  This dependency on
>/dev/null is bothering me.

I don't like it a lot, but I think it's safer than any other choice.
I made sure to fail safe, so the only problem is if /dev/null is a
file that does things when opened and closed (like one of those tape
devices).  And if that's the case, so much will break that this is
lost in the noise.

Any other test I can think of is substantially ickier - like calling
uname().

>> We already have support for selecting auxiliary libraries based on the
>> processor type; it shouldn't be too hard to extend that to OS revision
>> (call uname, or get the kernel to pass up its revision number in the
>> aux vector).
>
>No, this is not what I meant.  I don't talk about not using some code
>at runtime, I mean avoinding to generate code I'll never use in the
>first place.

I see.  Your idea is good.  The header doesn't have to be generated:
just do e.g.

#ifdef __linux__
#if KERNEL_LOWEST_REV >= 1
#define HAVE_O_DIRECTORY
#define HAVE_TIOCGPTN
...
#endif
#if KERNEL_LOWEST_REV >= 3
...
#endif
#endif
#elif defined __hurd__
#if KERNEL_LOWEST_REV > 1
...
#endif
#endif
...

where KERNEL_LOWEST_REV is set by configure based on a --with switch
or --host=x-y-z1.2.3.

zw