[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130211143944.GF6181@port70.net>
Date: Mon, 11 Feb 2013 15:39:44 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 2/3] Have different definitions of
__pthread_tsd_main agree in size
* Jens Gustedt <jens.gustedt@...ia.fr> [2013-02-11 15:07:28 +0100]:
> the current model there is even the danger that environ and __environ
> split into two different objects.
>
> char **environ;
>
> int main(void) {
> return (long)&environ;
> }
>
> When compile-linking this with musl I get both symbols environ and
> __environ linked in.
>
and that is precisely what posix requires
> So it would at least be good that the internal use of it in musl would
> be consistent and the C library would not see two distinct objects.
>
no
"The ISO C standard and this volume of POSIX.1-2008 do not conflict
on the use of environ, but some historical implementations of environ
may cause a conflict. As long as environ is treated in the same way
as an entry point (for example, fork()), it conforms to both standards.
A library can contain fork(), but if there is a user-provided fork(),
that fork() is given precedence and no problem ensues.
The situation is similar for environ: the definition in this volume of
POSIX.1-2008 is to be used if there is no user-provided environ to take
precedence. At least three implementations are known to exist that
solve this problem."
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
