Am 13.03.2026 um 23:20 schrieb Theo de Raadt:
> 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 :-) )
>>
>> On Fri, Mar 13, 2026 at 4:45 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
>> <lyndon@orthanc.ca> wrote:
>>>
>>> Calling setenv(3) as setenv("foo", NULL, 1) will SEGV.  This
>>> should return EINVAL as with setenv(NULL, "foo", 1).
> 
> Furthermore I disagree with this trend to "always return an error
> vaue".
> 
> An example is fclose(NULL).
> 
> That crashes.  It *SHOULD* crash, so that you can find and fix the bug.
> 
> 

Passing NULL to something expecting a non NULL value almost always is a
non-recoverable technical issue - an expected precondition is not met -
only solvable by changing code. Adding any complexity around this is
like catching a NullPointerException in Java, for example. Don't do it.
Get the users, who almost never can do anything about it to provide
meaningful crash reports.