I am not even remotely sure whether this is a bug: redefining getenv/setenv/et al.

[Peter Seebach]

So, for context, I'm aware that this is by no means a normal or reasonable use
case. I'm the maintainer of pseudo, a program used by build systems to allow
developers to create filesystems with permissions, modes, and device nodes,
without actually requiring root privileges. (Similar to fakeroot.)

Pseudo works by preloading itself as a shared library, using LD_PRELOAD (on
Linux), and replacing large hunks of the C library. The client code can
spawn a server, which of course doesn't want LD_PRELOAD set.

And I have for some time had a very strange problem, which is that
"sometimes" unsetting LD_PRELOAD doesn't work. Well, it turns out that the
issue is that bash provides its own definitions of getenv/setenv/unsetenv,
and they don't automatically modify environ.

It seems pretty obvious to me that there are Sound Technical Reasons for the
shell to wish to maintain an "environment" which is not actually stored in
environ, so that part makes sense.

What surprised me is the use of the same names as the C library functions
which manipulate environ. I had a bit of test code to the effect of:
        char *u = getenv("LD_PRELOAD");
        pseudo_diag("LD_PRELOAD: %s\n", u ? u : "<unset>");
        for (int i = 0; environ[i]; ++i) {
                if (!strncmp(environ[i], "LD_PRELOAD=", 11)) {
                        pseudo_diag("environ[%d]: %s\n", i, environ[i]);
                }
        }

and this would emit things like:
        LD_PRELOAD: <unset>
        environ[75]: LD_PRELOAD='libpseudo.so

which was very, very, surprising. I showed this behavior to a fair number of
people, and none of them thought of "is it possible that the process your
library is attached to has redefined getenv and setenv?".

So what I'm wondering is, why were these functions given the same names as
the library functions, rather than having names like bash_setenv, etc? It
seems risky. (I think it's technically undefined behavior, but as the person
whose library replaces most file-related calls with custom versions that talk
to a database server to fake results, I think I'll refrain from throwing
stones on that topic.)

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.