3 ms·

Very similar to people using node.getenv in hot sections of code and the resulting not understanding what's happening. https://github.com/nodejs/node/issues/31

Very similar to people using node.getenv in hot sections of code and the resulting not understanding what's happening. https://github.com/nodejs/node/issues/3104 https://github.com/nodejs/node/issues/3104 When you call out to the sys or libc things are going to happen and you should try and be aware of what those are.

fao_ 5y ago
Sorry... what? Why the hell was an application using env() to carry application state?! The environment list is created at init, it's literally placed right behind the C argument list as an array -- AUXV if you want to go read the ABI Specification for it. Therefore, anything you grab using getenv() can be considered to be static (Barring use of setenv), so the proper and correct thing to do is shove the things you need into a variable at init. Unless you yourself are editing it, but you should still use a variable because variables are typed and getenv is not (Thinking along the lines of storing port information, or whatever, where you need to parse it into a string to get it into the environment, and then need to parse it out of a string). For things like $HOME, those only ever change once, and you should really have a list of those that you check, because you will want to check XDG_HOME_DIR, and a few other areas. So you will want those in a list anyway, might as well do it at creation time when the data is fresh. Anything you set with setenv() only alters the your environment state, and that will carry down to newly created children at creation time. So the only reason I can think of why anyone would do this would be to communicate data to child processes. Except there are so, so many better and non-stringly typed ways to do this, including global variables. Child processes inherit copies(?) of their parent's state, you can just use that, so there is literally, NO reason ever to do this.
- thelopa 5y ago
  … unless you intend to exec after forking
  - fao_ 5y ago
    Sure, but just use execvp and it's a damn sight safer because you know exactly the state of your child's environment state. You can see this in the CERT C coding guidelines: https://wiki.sei.cmu.edu/confluence/display/c/ENV03-C.+Sanitize+the+environment+when+invoking+external+programs https://wiki.sei.cmu.edu/confluence/display/c/ENV03-C.+Sanit... also ENV02-C comes into effect, as well, if your program is invoked with SOME_INTERNAL_VARIABLE=1 PORT=2000 ./prog then you try to invoke your child with: setenv("SOME_INTERNAL_VARIABLE", "2", 1); (fork blah blah)

fao_ 5y ago

Sorry... what? Why the hell was an application using env() to carry application state?! The environment list is created at init, it's literally placed right behind the C argument list as an array -- AUXV if you want to go read the ABI Specification for it. Therefore, anything you grab using getenv() can be considered to be static (Barring use of setenv), so the proper and correct thing to do is shove the things you need into a variable at init. Unless you yourself are editing it, but you should still use a variable because variables are typed and getenv is not (Thinking along the lines of storing port information, or whatever, where you need to parse it into a string to get it into the environment, and then need to parse it out of a string). For things like $HOME, those only ever change once, and you should really have a list of those that you check, because you will want to check XDG_HOME_DIR, and a few other areas. So you will want those in a list anyway, might as well do it at creation time when the data is fresh. Anything you set with setenv() only alters the your environment state, and that will carry down to newly created children at creation time. So the only reason I can think of why anyone would do this would be to communicate data to child processes. Except there are so, so many better and non-stringly typed ways to do this, including global variables. Child processes inherit copies(?) of their parent's state, you can just use that, so there is literally, NO reason ever to do this.

thelopa 5y ago
… unless you intend to exec after forking
- fao_ 5y ago
  Sure, but just use execvp and it's a damn sight safer because you know exactly the state of your child's environment state. You can see this in the CERT C coding guidelines: https://wiki.sei.cmu.edu/confluence/display/c/ENV03-C.+Sanitize+the+environment+when+invoking+external+programs https://wiki.sei.cmu.edu/confluence/display/c/ENV03-C.+Sanit... also ENV02-C comes into effect, as well, if your program is invoked with SOME_INTERNAL_VARIABLE=1 PORT=2000 ./prog then you try to invoke your child with: setenv("SOME_INTERNAL_VARIABLE", "2", 1); (fork blah blah)