expose creating windows-style envblock from current environment

Yitzchak Scott-Thoennes sthoenna@efn.org
Mon Oct 24 10:02:00 GMT 2005

On Mon, Oct 24, 2005 at 11:48:03AM +0200, Corinna Vinschen wrote:
> On Oct 23 18:08, Yitzchak Scott-Thoennes wrote:
> > I need to translate the current environment in a cygwin C program to
> > an envblock suitable for calling CreateProcess directly, and couldn't
> > think of a better way than the following patch.
> I'm wondering why that's necessary at all.  You have access to the app's
> POSIX environment and you know by a simple look into Cygwin which
> variables have to be path converted and which not.  That can be done
> using cygwin_conv_to_win32_path/cygwin_posix_to_win32_path_list.  Looks
> like a task easily accomplished inside of the application.

I seem to recall changes over time in which variables get converted
(or forced to exist) it would be nice, though not mandatory, to
automatically stay in synch.  Unless you are outright rejecting
having a way to do this, I'll play with it some more.  Perhaps
a new function would be better, but I don't know how to get a new
function exported by the dll.

> > But I think there's something I'm not understanding; with the free()
> > calls in place, it coredumps, though checking the code in environ.cc
> > seems to show that all the freed chunks should have been properly
> > allocated.
> envp and the envp members are allocated on the cygheap using cmalloc()
> and cstrdup() so you must free them with cfree().

(quietly) Oh.
> > As an aside, does the build_env call in spawn.cc leak?
> How?

By never freeing moreinfo->envp in the parent?  I couldn't follow how
moreinfo/ciresrv are being used, other than that they get passed somehow
to the child.

Thanks for looking at this and giving feedback.

More information about the Cygwin-patches mailing list