Re: setenv if value=NULL, what say standard? Bug?

[Rich Felker <dalias@libc.org>]

On Wed, Apr 22, 2015 at 09:26:57PM -0400, Jean-Marc Pigeon wrote:
> > I think the only safe conclusion is that the application is
> > incorrect and should ensure that setenv() is never called with a
> > NULL value.
> > 
> Checked glibc, My understanding, it set something as
> "name="
> in the environment, so the variable is present but
> value is "empty"i (top application to decide what to do).
> uclibc does something similar (as far I can tell looking
> at source code)..
> 
> 
> The application is not careful enough, but not incorrect as such.

It's definitely incorrect. It's doing something that invokes undefined
behavior.

> Note: we may have tons of applications with the same problem.
> if we keep musl setenv like that, musl will be seen as quite unreliable.

No, actually glibc is fixing this bug (maybe they already did). See
the thread beginning here:

https://sourceware.org/ml/libc-alpha/2015-03/threads.html#00449

My understanding is that glibc is planning to do, or already does in
the latest version, exactly what musl is doing.

> If this situation is indeed UB, there is 2 options for musl:
> 1) Swallow the problem nicely... as glibc and uclibc does.
> 2) Report an error.. EINVAL? (and document it in manual)
> 
> Crashing at "libc" level is not an option.

I can see how it might seem like that at first, but crashing is
actually the best possible behavior. Options 1 and 2 cover up a
potentially serious bug -- it's not clear what the application was
trying to do, most likely nobody even thought about what they were
trying to do, and even if they did have something in mind it's not
reliable or portable. The glibc wiki has some text taken from text I
wrote on the topic (copied from a stack overflow answer I gave) here:

https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointers

Specifically it covers why returning an error is not a good idea.

Rich