3 ms·
Their solution was that setenv leaks memory rather than overwriting in place. FreeBSD does the same. See here for discussion: https://freebsd-current.freebsd.n
by ori_b 1y ago
Their solution was that setenv leaks memory rather than overwriting in place.
FreeBSD does the same. See here for discussion: https://freebsd-current.freebsd.narkive.com/NwqZQDWm/fix-for-memory-leak-in-setenv-unsetenv https://freebsd-current.freebsd.narkive.com/NwqZQDWm/fix-for...
- monocasa 1y agoSure. But practically the amount you leak is infinitesimal. For a lot of applications that's the right call given the rest of the posix semantics you're constrained to and the kinds and frequency of data you pass via env vars.
- cbsmith 1y agoAn infinitesimal leak becomes a problem if it is done an infinite number of times... execve seems like the preferable choice on a lot of grounds.
- dwattttt 1y agoIt would be a problem, except that the behaviour you're moving away from is a stale pointer. So surely any application that'd be leaking under that new behaviour would be crashing today.
- 1718627440 1y agoNo it always leaks, regardless if your program now correctly invalidates all derived pointers upon calling setenv.
- ori_b 1y agoThe same advice applies to a correct program regardless of the implementation: using setenv is a bug. Only use getenv. Getenv in a program without setenv is fine in both implementations. Setenv is unusable with all conforming implementations. To pass environments to children, use execve. The Linux behavior allows a careful single threaded program to use setenv correctly. The BSD/Solaris behavior makes all usage incorrect, but the incorrectness comes in the form of a memory leak, which is preferable to a security issue, usually. There's no correct, portable use of setenv. If you call it, it's a bug.
- monocasa 1y agoWhich is why I said > frequency of data Practically, if you're moving enough data through setenv that the memory leaked versus the steady state fluctuation of the program is at all visible, you've got much bigger problems.
- ori_b 1y agoYou don't need setenv. It's just a particularly broken way of assigning to a global char*.
- monocasa 1y agoAnd I personally don't use it or would be likely to approve a review that uses it. But it I were implementing POSIX and had to implement it, I would almost certainly make Sun's choice thinking of it as the least evil given the expected use cases.
- kokada 1y agoYes. Changing the implementation to the Solaris/FreeBSD solution now would probably break lots of applications that nowadays works without issue.