According to [1], windows does not support setenv, so for the patch to work
[3], would need to add it.
With the possibility of setenv going further [2], I am submitting in this
thread, the patch to add setenv support on the windows side, avoiding starting
a new trhead.
It is based on pre-existi
Ranier Vilela writes:
> According to the documentation at:
> https://wiki.sei.cmu.edu/confluence/display/c/POS34-C.+Do+not+call+putenv%28%29+with+a+pointer+to+an+automatic+variable+as+the+argument
> "Using setenv() is easier and consequently less error prone than using
> putenv()."
> putenv is pr
According to the documentation at:
https://wiki.sei.cmu.edu/confluence/display/c/POS34-C.+Do+not+call+putenv%28%29+with+a+pointer+to+an+automatic+variable+as+the+argument
"Using setenv() is easier and consequently less error prone than using
putenv()."
putenv is problematic and error prone, better
Mark Dilger writes:
> Please see the man page for putenv. Are you certain it is safe to
> free the string passed to putenv after putenv returns? I think this
> may be implemented differently on various platforms.
POSIX requires the behavior the glibc man page describes:
The putenv() functi
On 12/16/19 1:22 PM, Ranier Vilela wrote:
Hi,
On exec.c, have two memory leaks, and a possible access beyond heap bounds, the
patch tries to fix them.
According to documentation at:
https://en.cppreference.com/w/c/experimental/dynamic/strdup
"The returned pointer must be passed to free to avo
