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] |
On 05/29/2013 05:41 PM, Carlos O'Donell wrote:
On 05/29/2013 03:09 AM, Stephan Bergmann wrote:On 05/29/2013 06:56 AM, Carlos O'Donell wrote:- User changeable environment variables that impact library runtime behaviour is dangerous. * Could you specifically point out what you find dangerous? I see no more danger than we already face when adding a new API or reviewing code changes. How is this different than all of the other work we do?One general problem of env vars is that they can all too easily affect processes they were not intended to affect (like when the target process spawns another process).Stephan, For the record, are you for or against using environment variables to tune library behaviour? You have made it clear that you are worried that the average user might not understand the implications of environment variables. Resolving that is going to be a process of education, but it is a downside to this feature. The user needs to be sufficiently educated about environment variables to understand they are passed on to child processes. My opinion is that users already understand this and that it is a feature, and that an API will help them reset all defaults if required before spawning. They can do that today by clearing GLIBC_* env vars along with the full list of LD_* and MALLOC_* env vars, but we will provide some convenience functions for this.
I wasn't thinking so much about clueless end-users in front of the shell, but rather about programmatic uses of env vars. From my past experience (developing LibreOffice), LD_LIBRARY_PATH is probably a good example:
For one example, some test code run during the build needing LD_LIBRARY_PATH to find libs at "wrong" locations (in the build output tree rather than the product's install location), but spawning as subject-under-test an installed product that should /not/ be fooled into picking up the wrong libs, so having to tunnel the original LD_LIBRARY_PATH setting through the test code so that it can reset it accordingly when spawning the subject-under-test (using differently named env vars on different platforms, of course).
For another example, Sun's java traditionally re-spawning itself after modifying LD_LIBRARY_PATH so it finds its own libs in its various jre sub-dirs, but then forgetting to reset LD_LIBRARY_PATH when spawning another process via java.lang.Runtime.exec (so that if that process is LibreOffice, which happens to instantiate in-process a JVM from another JRE installation on the machine, things start to go bad).
(The example of LD_LIBRARY_PATH also indicates that what is required is not always functionality to clear the env, but sometimes it is functionality to reset an env back to a state before it got overridden.)
It's fun like that which prompts me to point out that general problem with env vars. But for your specific question, I fear I need to chicken out. I see both the pros and the cons, and I'm not sure what an ideal solution would look like,
Stephan
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |