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

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

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

The informative part of the https://pubs.opengroup.org/onlinepubs/9699919799/
for the uname command reports:

QUOTE
It was suggested that this utility cannot be used portably since the format
of the symbols is implementation-defined. The POSIX.1 working group could
not achieve consensus on defining these formats in the underlying uname()
function, and there was no expectation that this volume of POSIX.1-2017
would be any more successful.
END QUOTE

The informative material for the subroutine reports:

QUOTE
The values of the structure members are not constrained to have any relation
to the version of this volume of POSIX.1-2017 implemented in the operating
system. . . .
The uname() function originated in System III, System V, and related
implementations, and it does not exist in Version 7 or 4.3 BSD. The values
it returns are set at system compile time in those historical
implementations.
END QUOTE

I find no evidence that posix requires the kind of interpretation you are
expecting. The "cannot be used portably" status, "lack of any relation"
for the values to POSIX.1-2017, and the not-set-at-compile-time
implementations that came after the initial ones would be examples that
tend to confirm that FreeBSD is not violating POSIX via FreeBSD's
behavior.

I'm afraid that you can not look to POSIX to give you the kind of guarantees
that you are looking for. It is more OS specific as to what, if any,
interface(s) provide the kind of guarantees you are looking for. (sysctl for
FreeBSD seems to cover some of it via some of its read-only content.)
It is true that some systems could choose to define uname in a way that,
for that kind of system, would have the properties.

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