Michael B Allen wrote:
Is the string returned by getenv guaranteed to be the same string supplied
to putenv plus the offset of the variable name and equals sign?
No, because there is no putenv() in the Standard C library.
As far as C is concerned, the environment is read-only.
Because of API constraints I do not want to save a pointer to the string
passed to putenv but I need to be able to free it later or I will have
a memory leak.
... and this may be one of the reasons the Standard doesn't
define putenv(): deciding who manages the memory could turn out
to be troublesome. Should putenv() copy the provided string,
or should it require that the string continue to exist? If it
copies, what should it do if unable to allocate memory to hold
the string (in particular, can it free() a prior value and then
fail to set the new one, or must it guarantee all-or-nothing)?
Questions like this can, of course, be settled, even if by
arbitrary choice. However, the Committee chose not to settle
it, writing (in the Rationale)
A corresponding putenv function was omitted from the
Standard, since its utility outside a multi-process
environment is questionable, and since its definition
is properly the domain of an operating system standard.
It's possible that this is face-saving language for "We couldn't
find a way to reconcile the conflicting behaviors of different
existing putenv() implementations, so we punted." But face-saving
or face-value, that's the state of affairs: There's no putenv() in
the C library, and systems that provide it as an extension have
defined their extensions in somewhat different ways.
--
Eric Sosman
es*****@acm-dot-org.invalid