enh <enh@google.com> wrote:

> might be worth filing an austin group bug, since their ERRORS section
> only mentions name:
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/setenv.html
> 
> (leaving it unclear just how an implementation can "copy" a null
> string... that strlen() being the point at which all the
> implementations i just checked currently crash :-) )


I think these proposal are junk.

Historically, the error return is not checked.

If it crashes for invalid input that's a moment a bug can be found and fixed.

If it returns an error value, which noone looks at, the bug will not be
identified, and the code will keep running and potentially depend upon
an operation which is now a no-op.

Which situation is more dangerous?

The case where it didn't crash internally on invalid input, and returned
an indication that it is a no-op, which noone looks at.

Efforts to demand that return values are always checked never seem to
gain sufficient footing to actually prevent important breakage.  And
the community will never change.  As an example, we provided a perfectly
useful return value for strlcpy() and a loud segment of the community
said that because the return value isn't checked that is our fault.  If
the community cannot learn for new APIs, there is no chance they will
ever learn when an existing API is changed in a way they are not aware of;
even if they became aware, an industrial effort to expand return value
checks for setenv() will not ever materialize.