Date: Wed, 21 Dec 2022 20:01:25 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 268479] lib/libc/stdlib/getenv.c may have a problem with putenv() Message-ID: <bug-268479-99-HKVpgBULmN@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268479-99@https.bugs.freebsd.org/bugzilla/> References: <bug-268479-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268479 --- Comment #3 from Dennis Clarke <dclarke@blastwave.org> --- (In reply to Mark Millard from comment #2) I must agree fully. There does not seem to be a reason to disallow a name=3Dvalue pair to exist where the value is nothing at all. I see the words "the value shall be composed of characters from the portable character set" but no where does the POSIX spec claim that we *must* have some characters after the equal '=3D' to form a "value". So I guess putenv() and friends are doing what they claim to do. Correctly. That leads to the other problem wherein env var names such as UNAME_s can override the uname(3) struct members within FreeBSD. If we have an env var name=3Dvalue such as "UNAME_r=3D" then how shall a process ever determine the uname(3) release data? It seems that I need to write my own hackary to walk through extern char **environ and mangle it myself? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268479-99-HKVpgBULmN>