This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Preload infrastructure.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 22 Oct 2013 14:56:08 +0000
- Subject: Re: [PATCH] Preload infrastructure.
- Authentication-results: sourceware.org; auth=none
- References: <20131021193617 dot GA29829 at domone dot podge>
On Mon, 21 Oct 2013, Ondrej Bilka wrote:
> OK to commit?
Please don't ask that for something that is clearly nowhere near ready -
for example, doesn't integrate at all into the glibc build system, doesn't
follow the GNU Coding Standards consistently, hardcodes "gcc" instead of
the appropriately configured compiler for the system for which glibc is
being built, hardcodes libc.so.6 rather than adapting for different
SONAMEs on different targets, introduces an obvious security hole (and
code that won't work on multi-user systems) by hardcoding a path in /tmp,
fails to use symbol versioning / otherwise ensure that the library only
exports the desired symbols and no others, isn't thread-safe (look at all
the use of static variables in strncat where the code could end up using
some variables from one thread and some from another), has no copyright /
license notices, is not documented in the glibc manual, ....
What you posted may be an early-stage example to inform discussion. But
you need to write up a much more extended self-contained explanation of
the idea (but with references to prior art in this area), thinking
carefully about the audiences for both that explanation and for the
library itself. One obvious issue to consider is that some users may want
only diagnostics for invalid usages and not those for performance, or only
those for performance of particular functions and not others.
Joseph S. Myers