This is the mail archive of the cygwin-patches mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Make getenv() functional before the environment is initialized

On Apr 21 16:32, Pierre A. Humblet wrote:
> ----- Original Message ----- 
> From: "Christopher Faylor" <>
> To: <>
> Sent: Friday, April 21, 2006 4:12 PM
> Subject: Re: [Patch] Make getenv() functional before the environment is 
> initialized
> >>
> >>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
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]