[Bug 268479] lib/libc/stdlib/getenv.c may have a problem with putenv()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268479

--- Comment #14 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Dennis Clarke from comment #12)

To know the the boot FreeBSD kernel information (for the active architecture
when more than one is possible) in a context known to be FreeBSD, use:

sysctl(8) - get or set kernel state

or:

sysctl, sysctlbyname, sysctlnametomib(3) - get or set system information

I'm unsure why other programming interfaces should be a strictly
redundant presentation of the same information as the subset of sysctl
information that provides defaults for the interface(s) you are trying
to use for some reason.

In other words, if you use the right interface, you can "can actually
know the system we are running on". Why do you insist on using the
interface that you are trying to use for this? FreeBSD would be
broken in various respects if its standard operating procedures in
various places suddenly stopped working in order to not return
different uname(1) and uname(3) results than sysctl (and its
variants) would return.

FYI:

FreeBSD 4.8 looks to be the first release that uname(1) documents
with:

ENVIRONMENT
     An environment variable composed of the string UNAME_ followed by any
     flag to the uname utility (except for -a) will allow the corresponding
     data to be set to the contents of the environment variable.

But, interestingly, 6.3 looks to be the first that uname(3) documents
with:

ENVIRONMENT
     UNAME_s  If the environment variable UNAME_s is set, it will override the
              sysname member.

     UNAME_r  If the environment variable UNAME_r is set, it will override the
              release member.

     UNAME_v  If the environment variable UNAME_v is set, it will override the
              version member.

     UNAME_m  If the environment variable UNAME_m is set, it will override the
              machine member.

In other words: these were added later than uname(1) and uname(3) were
originally added. But they have been around for a while.

-- 
You are receiving this mail because:
You are the assignee for the bug.