On 04/23/2015 09:22 AM, Szabolcs Nagy wrote:
> * Jean-Marc Pigeon <jmp@safe.ca> [2015-04-23 08:58:50 -0400]:
>>> 
>>>> so the library (glibc and old libc) used for linux over the
>>>> years defined an expected behavior to this "UB".
>>> 
>>> No, that was merely a bug in glibc, not a feature.
>> 
>> Hmmm... glibc-2.21, setenv.c explicitly check the value NULL 
>> condition, so situation is checked, you could object about the
>> way program handle it, but it is not a bug (situation expected
>> and addressed).
>> 
> 
> you are wrong, glibc actually corrupted then environ on NULL 
> argument and this was fixed recently
> 
> http://sourceware.org/git/?p=glibc.git;a=commit;h=03c1e456b079929a8290aeb4aadb05c0df73bfd2
>
>  stop mixing runtime failure with ub, that leads to nonsense 
> discussions.
> 
glibc-2.12-1.132.el6_5.2.x86_64
I do not confirm env corruption, try:

#include        <stdio.h>

main()

{
#define ENVNAME "BIGRE"

(void) setenv(ENVNAME,getenv("MISSING_FROM_ENV"),1);
(void) fprintf(stdout,"1 env %s=<%s>\n",ENVNAME,getenv(ENVNAME));
(void) setenv(ENVNAME,"",1);
(void) fprintf(stdout,"2 env %s=<%s>\n",ENVNAME,getenv(ENVNAME));
(void) setenv(ENVNAME,"something",1);
(void) fprintf(stdout,"3 env %s=<%s>\n",ENVNAME,getenv(ENVNAME));
}

What I am trying to explain, you have something not
defined in spec, was resolved in a way (you may not like, I agree)
for EONs.

Now "you" decide, to resolve UB another way, you may
have tons of applications in jeopardy.



-- 

A bientôt
===========================================================
Jean-Marc Pigeon                        E-Mail: jmp@safe.ca
SAFE Inc.                             Phone: (514) 493-4280
  Clement, 'a kiss solution' to get rid of SPAM (at last)
     Clement' Home base <"http://www.clement.safe.ca">
===========================================================