[test] PATCH: putenv usage incorrect
http://tinyurl.com/72sj8 This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others). Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD). I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others).
Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD).
I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions.
setenv() is a very recent addition to POSIX, IIRC. Older Unix versions might not support it. POSIX setenv() takes three arguments, your patch passes only two. Your patch doesn't check the value returned by setenv() or putenv(). Regards, m
On 4/26/05, Martin Wille <mw8329@yahoo.com.au> wrote:
Caleb Epstein wrote:
This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others).
Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD).
I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions.
setenv() is a very recent addition to POSIX, IIRC. Older Unix versions might not support it.
OK, would you know of a better way to determine which "type" of putenv is available instead? E.g. is it the one that takes a const char* and copies, or the one that takes a char* and inserts it into the environment in-place. Using the wrong semantic will lead to either memory leak (bad) or undefined behavior (worse).
POSIX setenv() takes three arguments, your patch passes only two.
Whoops. Lets try that again. See attached. I even compiled and ran the test programs on Linux (gcc 3.3.5) and Windows (VC 7.1) this time :-)
Your patch doesn't check the value returned by setenv() or putenv().
Nor did the original. I'm just trying to get this code working in order to clear up some of the test failures. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 4/26/05, Martin Wille wrote:
[...]
setenv() is a very recent addition to POSIX, IIRC. Older Unix versions might not support it.
OK, would you know of a better way to determine which "type" of putenv is available instead? E.g. is it the one that takes a const char* and copies, or the one that takes a char* and inserts it into the environment in-place. Using the wrong semantic will lead to either memory leak (bad) or undefined behavior (worse).
I once wrote my own version of putenv() in order to avoid the memory leak problem. I'm afraid this is a nasty problem, because POSIX putenv() doesn't copy but doesn't assume ownership, either. setenv() might leak for that reason, too. You can check for the platforms you know to support setenv by using the various macros they supply (messy, I know). Every *BSD I know of and Linux do. setenv() was added to POSIX in IEEE Std 1003.1-2001, if I understand correctly. So setting _POSIX_C_SOURCE before #including any POSIX header and checking for _POSIX_VERSION >= 200112L should catch all POSIX implementations that added setenv() recently. [...]
Your patch doesn't check the value returned by setenv() or putenv().
Nor did the original. I'm just trying to get this code working in order to clear up some of the test failures.
Well, I don't know the context of the code. I can't say whether it is ok to ignore the result here. I just wanted to state what I've seen. Regards, m
On 4/26/05, Martin Wille <mw8329@yahoo.com.au> wrote:
Caleb Epstein wrote:
On 4/26/05, Martin Wille wrote:
[...]
setenv() is a very recent addition to POSIX, IIRC. Older Unix versions might not support it.
OK, would you know of a better way to determine which "type" of putenv is available instead? E.g. is it the one that takes a const char* and copies, or the one that takes a char* and inserts it into the environment in-place. Using the wrong semantic will lead to either memory leak (bad) or undefined behavior (worse).
I once wrote my own version of putenv() in order to avoid the memory leak problem. I'm afraid this is a nasty problem, because POSIX putenv() doesn't copy but doesn't assume ownership, either. setenv() might leak for that reason, too.
You can check for the platforms you know to support setenv by using the various macros they supply (messy, I know). Every *BSD I know of and Linux do. setenv() was added to POSIX in IEEE Std 1003.1-2001, if I understand correctly. So setting _POSIX_C_SOURCE before #including any POSIX header and checking for _POSIX_VERSION >= 200112L should catch all POSIX implementations that added setenv() recently.
[...]
Your patch doesn't check the value returned by setenv() or putenv().
Nor did the original. I'm just trying to get this code working in order to clear up some of the test failures.
Well, I don't know the context of the code. I can't say whether it is ok to ignore the result here. I just wanted to state what I've seen.
Perhaps Genndiy could comment on whether or not this code is really even needed. It seems to only be used in a single test program. -- Caleb Epstein caleb dot epstein at gmail dot com
Perhaps Genndiy could comment on whether or not this code is really even needed. It seems to only be used in a single test program.
Unfortunately I did not have enough time to incorporate this staff into rest of Boost.Test. So for now it's only test case for facilities about to be used. Gennadiy
This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others).
From current regression results it seems that putenv is not an issue anymore . Almost. The only compiler that doesn't know about neither putenv nor setenv Cameau. Any help?
Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD).
I could switch to setenv (actually it's more natural for my puroses). But this is not my primary problem at the moment.
I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions.
If I am not mistaken getenv is. Anyway I switched to "using namespace std" and it shouldn't be an issue anymore. Gennadiy
participants (3)
-
Caleb Epstein -
Gennadiy Rozental -
Martin Wille