You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Alex Clemmer (JIRA)" <ji...@apache.org> on 2016/07/21 18:01:20 UTC
[jira] [Created] (MESOS-5880) Make `environment` semantics uniform
across Windows and POSIX
Alex Clemmer created MESOS-5880:
-----------------------------------
Summary: Make `environment` semantics uniform across Windows and POSIX
Key: MESOS-5880
URL: https://issues.apache.org/jira/browse/MESOS-5880
Project: Mesos
Issue Type: Bug
Components: stout
Reporter: Alex Clemmer
Assignee: Alex Clemmer
Preliminary investigation shows that our current Windows implementations of `os::environment`, `os::setenv`, and `os::getenv` fail to set flags in some cases. This leads to test failures on Windows in:
* `flags_tests.cpp` (MESOS-3437), namely `LoadFromEnvironment`
* `os_tests.cpp` (MESOS-3441), namely `Environment`
A preliminary investigation shows:
* These failures occur because the C standard API for environment variables are incompatible. That is, `os::environment` uses the C standard implementation of the `environ` macro, while `os::setenv` and `os::putenv` use the Win32 APIs for environment variables, like `GetEnvironmentVariable` and `SetEnvironmentVariable`. But, `SetEnvironmentVariable` does not affect the environment reported by `environ`, so updates are not reflected when we call `os::environ`.
* It is unlikely we will want to use the C equivalents of the `Get/SetEnvironmentVariable`, (that is, `setenv_s` and friends), because they have different behavior on Windows than on other libc implementations. Specifically, on Windows `setenv_s("yourvar", "")` unsets the variable `yourvar`, while on other implementations, it sets the value of `yourvar` to be the empty string.
* But, transitioning to a pure Win32 implementation (i.e., one using `Set/GetEnvironmentVariable`, `GetEnvironmentStrings`, etc.), probably requires changing or getting rid of `os::environment*` APIs. Specifically, `os::raw::environment` and `os::environmentp` will probably be eliminated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)