actually, re-reading POSIX, openbsd and android are already returning
EINVAL in cases where we could just blow up: none of the environment
functions are specified to return EINVAL for anything other than
unexpected '='s/empty strings. null pointers aren't mentioned...

On Mon, Mar 16, 2026 at 2:12 PM enh <enh@google.com> wrote:
>
> 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.)