On Fri, Mar 13, 2026 at 6:20 PM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> 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.

yeah, iirc NetBSD has DIAGASSERT() macros for this kind of thing ...
but i think they ship with them disabled?

on Android i've (ab)used fortify by pretending that this kind of thing
is a fortify error and crashing with a nice clear "fclose: null FILE*"
abort message (because it turned out that a lot of app developers --
both 1p and 3p -- were unable to debug a null pointer dereference
without help).

but while we have that for stdio (because "i didn't check the return
value of fopen() and just assumed it was fine" turns out to be a
common error even in shipping code) but i've yet to see an issue with
the environment functions, so they still just fail quietly with
EINVAL.

(the issue we _do_ see with the environment functions is people not
understanding that they're not thread-safe.)