Date: Sun, 25 Dec 2022 08:46:37 +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-b13dkaSzWI@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 #10 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Tatsuki Makino from comment #9) I'm confused about your point. uname(1) and uname(3) are not the same as the sysctl but can use the sysctl, absent an overriding UNAME_* . Various usages of uname(1) and uname(3) do not want the value that sysctl provides: some deliberately different UNAME_* assignments are used at times. sysctl values are provide defaults. lib/libc/gen/getosreldate.c's getosreldate() checks for OSVERSION in the environment and only uses the sysctl when OSVERSION is not found. (Analogous to UNAME_* usage.) Also, uname -U is not ever via a sysctl: the default is from the world (not kernel) __FreeBSD_version macro value for uname's compilation context. kern.build_id, kern.ident, kern.osreldate, kern.osrelease, and kern.version reflect the actual kernel running, not the one being simulated in, say, a chroot into an older version of world. Various things instead need identify the simulated kernel version being targeted instead. Mostly this involves providing alternate definitions to kern.osreldate and kern.osrelease . Similarly, there are contexts in which the hw.machine and hw.machine_arch from the booted kernel are inappropriate to identifying a simulated/emulated environment. --=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-b13dkaSzWI>