4 ms·

An 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 ago
  It 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 ago
    No it always leaks, regardless if your program now correctly invalidates all derived pointers upon calling setenv.
  • ori_b 1y ago
    The 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 ago
  Which 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 ago
    You don't need setenv. It's just a particularly broken way of assigning to a global char*.
    • monocasa 1y ago
      And 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.