From: enh Subject: Re: setenv(3) segfaults when value == NULL To: Theo de Raadt Cc: "Lyndon Nerenberg (VE7TFX/VE6BBM)" , tech@openbsd.org Date: Mon, 16 Mar 2026 15:31:26 -0400 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 wrote: > > On Fri, Mar 13, 2026 at 6:20 PM Theo de Raadt wrote: > > > > enh 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) > > > 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.)