This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Preload infrastructure.


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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]