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 14:12:01 -0400 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.)