argh!

[Ulrich Drepper]

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.

> 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've thought a bit about this.  I could imagine to generate a header

	libc-assumptions.h

at configure time.  The header would contain definitions like

	#define _LIBC_ASSUME_WORKING_O_DIRECTORY	1

and so on.  The source code then would honor these definitions.  There
would be a central list of all such defines and the configure files
would add appropriate entries, perhaps based on extra commandline
parameters etc.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------