This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: argh!
- To: Zack Weinberg <zack@rabi.columbia.edu>
- Subject: Re: argh!
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 19 Oct 1998 17:44:54 -0700
- Cc: libc-hacker@cygnus.com
- References: <199810200035.UAA27233@blastula.phys.columbia.edu>
- Reply-To: drepper@cygnus.com (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 `------------------------
- Follow-Ups:
- Re: argh!
- From: Zack Weinberg <zack@rabi.columbia.edu>
- References:
- Re: argh!
- From: Zack Weinberg <zack@rabi.columbia.edu>