| Age | Commit message (Collapse) | Author |
|---|
|
putenv(3) and friends aren't thread-safe regardless of how you slice
it; a global lock around all environment operations (like before)
keeps things safe as far as our own operations go, but we have
absolutely no control over what libc or a library dragged in by a
driver/NIF does -- they're free to call getenv(3) or putenv(3)
without honoring our lock.
This commit solves this by setting up an "emulated" environment which
can't be touched without going through our interfaces. Third-party
libraries can still shoot themselves in the foot but benign uses of
os:putenv/2 will no longer risk crashing the emulator.
|
|
Various places that now reject null chars inside strings
- Primitive file operations reject it in filenames.
- Primitive environment variable operations reject it in
names and values.
- os:cmd() reject it in its input.
Also '=' characters are rejected by primitive environment
variable operations in environment variable names.
Documentation has been updated to document null characters
in these types of data as invalid. Currently these operations
accept null chars at the end of strings, but that will change
in the future.
|
|
|
|
* Add specs
* Change return signature to 'ok' instead of 'true'
|
|
|
|
|
|
New BIF os:unsetenv/1 which deletes an environment variable and
returns 'true'.
Does not change any old functionality.
Calls the libc function unsetenv(3) on UNIX and
SetEnvironmentVariableW(key, NULL) on Windows. The unicode support
is the same as for os:getenv and os:putenv.
|
|
|
|
|
|
Putenv and getenv needs to convert to the proper environment
strings in Unicode depending on platform and user settings for filename
encoding. Also erlexec needs to pass environment strings in an appropriate
way for kernel to pick up. All environment strings on the command
line, as well as home directory, is now passed in UTF8 on windows
and in whatever encoding you have on Unix, kernel tries to convert all
parameters and environments from UTF8 before making strings.
|
|
As a preparation for changing the calling convention for
BIFs, make sure that all BIFs use the macros. Also, eliminate
all calls from one BIF to another, since that also breaks
the calling convention abstraction.
|
|
|
