Danny Backx escreveu:
> Pedro,
>
> Attached is a proposed implementation for getenv, setenv, unsetenv. I
> would put this in src/mingw/mingwex/getenv.c . A test program is in the
> other attachment.
>
>
Based on the Makefile.in patch looks like you meant mingw/mingwex/wince/
> I would propose using this to get libgcov to work on mingw32ce.
>
> Comments, or can I commit and change libgcov to use this ?
>
>
Humm, I had an instant reaction to say no, then I though about it some
more, and I was inclined to say yes, but... thinking some more, I don't
think this is appropriate for common mingw/ code. Please keep reading.
> + * We store stuff in HKEY_CURRENT_USER under the key "environment".
> + *
I think whatever comes out of this patch, it this needs to be put into
an addicional subdir, like
HKEY_CURRENT_USER/MinGWce/environment, or
HKEY_CURRENT_USER/gcov/environment.
As it is, there is a risk of collision. Plus, if we in the future add
more keys to the registry, they'll
be grouped.
> +
> +char *getenv(const char *name)
> +{
>
>
(...)
> + r = RegOpenKeyEx(HKEY_CURRENT_USER, env, 0, 0, &k);
> + if (r != ERROR_SUCCESS)
> + return -1;
> +
>
Return NULL ?
---
The thing with this kind of global environ implementation is that since
it delegates all work to the registry it should be ok to have it in
a static lib, (each dll/exe gets a copy), there is a major difference
to the the common implementations found in other operating systems.
The problem is that all apps will read/write to/from the same keys,
which is racy, while the most (all, maybe it is specified in some standard)
other implementations guaranty that each process has a private environment.
One way to solve that, is to have the app/dll read/cache the environ at
startup, and then read/write to the cached version. This brings up
a new problem,because then a dll linked with a static getenv, would
change its local environ cache and the other dlls and the main app
wouldn't see it. The easiest way to solve that would be to put
getenv/setenv/etc, in a dll of its own... This is where I come to
the conclusion that it is better to have a local private getenv in
libgcov and use that wrapped in __MINGWCE32__. I don't have a
problem with dlls, but I don't think this case it justifies an
extra dependency. This is the same rationale I used to introduce
src/gcc/libstdc++-v3/config/os/mingw32ce/runtimeopts.h, and replaced
every getenv call in libstdc++ with runtime_opts::force_new_p().
Cheers,
Pedro Alves
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
