This is the mail archive of the
mailing list for the Cygwin project.
Re: [Patch] Make getenv() functional before the environment is initialized
On Apr 21 16:32, Pierre A. Humblet wrote:
> ----- Original Message -----
> From: "Christopher Faylor" <email@example.com>
> To: <firstname.lastname@example.org>
> Sent: Friday, April 21, 2006 4:12 PM
> Subject: Re: [Patch] Make getenv() functional before the environment is
> >>But doesn't the program then have a pointer to memory that has been freed?
> >>That pointer can also be accessed after forks.
> >Isn't that always a possibility? You can't rely on the persistence of
> >the stuff returned from getenv().
> That's not my reading of
> "The string pointed to may be overwritten by a subsequent call to getenv(),
> but shall not be overwritten by a call to any other function in this volume
> of IEEE Std 1003.1-2001."
> Athough Posix allows the string to be overwritten, indicating that
> persistence is implied,
> it does not allow the pointer to become invalid.
> See also
> which says that the environment semantics make it inherently leaky.
> That's why I didn't hesitate calling cmalloc
The getearly function is only called in the initialization phase of the
application, when the Cygwin environment isn't initialized.
Why is it necessary to make this so complicated? Why isn't it
sufficient to return the value in a static buffer and tolerate that a
lib or application which hooks into this early stage of initialization
has to copy the value, if it needs it later on?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com