Michael Shapiro wrote: > pr_envp is the *original* environ pointer created by exec(). But if the > application has undergone a large number of setenv()s, then the array > may have needed to be resized, in which case that value isn't the > proper one anymore. (Technically a process could also reassign _environ > directly, although that isn't kosher from a POSIX perspective) So you > really need to lookup _environ and read the array it refers to. >
/usr/src/uts/common/os/exec.c builds the environment list on the initial thread's stack (next to the argv list). It is sized according to the number of elements in the parent's environment list -- or the list pointer to by envp arg in the case of execle(2) and execve(2) -- and includes space for the terminating NULL. That's all. As long as you haven't deleted a value, your very first call to putenv(3C) or setenv(3C) will result in environ being reassigned (to somewhere on the heap). This was the case before I made getenv(3) lockless ... http://blogs.sun.com/roller/page/pgdh?entry=caring_for_the_environment_making ... and it remains the case. However, unlike the old implementation, I don't grow the environment list one pointer at a time. Instead, I double the size of the array each time I run out of space. I also force a minimum of 128 pointers the first time it grows. But the big thing, is that I move environ every time I add a new value to the environment (because I copy the old array into the top of the new array and grow the list downwards). For the full gory details, see the above blog entry. The net result is that you MUST read environ directly every time ... if stuff is added to the environment, environ will move! The good news is that I always drop old versions of the environment list on the floor, so however old and out-of-date your copy of environ is, it should always point to a consistent snapshot. Sadly, it is still legal for applications to move environ around ... later versions of POSIX just say you really ought not to do it, and that you are one your own if you are using the supplied getenv() etc. My implementation checks to see if you have been naughty, and tries hard to be gracious ... it has to, because some of our test suites are quite naughty! Phil http://blogs.sun.com/pgdh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20050707/c9deff25/attachment.bin>
