This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] Fix environ.c on darwin
- From: Steven Bosscher <stevenb at suse dot de>
- To: Steven Bosscher <stevenb at suse dot de>, Andrew Pinski <pinskia at physics dot uc dot edu>, "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>
- Date: Thu, 28 Oct 2004 23:40:32 +0200
- Subject: Re: [PATCH] Fix environ.c on darwin
- Organization: SUSE Labs
- References: <255FAD68-2827-11D9-B7C0-000A95D692F4@physics.uc.edu> <200410282330.22318.stevenb@suse.de>
On Thursday 28 October 2004 23:30, Steven Bosscher wrote:
> On Wednesday 27 October 2004 16:47, Andrew Pinski wrote:
> > This is basically the patch from the PR for this (PR 17748) with
> > an additional comment which says why this is needed.
> > The problem is that even though darwin has a man page for environ,
> > it does not really have the variable but does have a function,
> > _NSGetEnviron, which does the same thing as the variable.
> >
> > OK? Built and tested on powerpc-darwin.
>
> Hmm I didn't know we are looking looking directly at enrivon.
> Can't we use getenv()&friends from POSIX?
Hmm I see...
runtime/environ.c:643
for (e = environ; *e; e++)
{
p = pattern_scan (*e, "GFORTRAN_NAME_", &n);
if (p == NULL)
continue;
st_printf ("GFORTRAN_NAME_%d %s\n", n, p);
}
Ugh, how ugly.
This only happens for GFORTRAN_NAME_xx and GFORTRAN_UNBUFFERED_xx.
Perhaps we should reconsider how to implement this option. What
about GFORTRAN_NAME=unitno1:nameprefix1,unitno2:nameprefix2, etc,
and something similar for GFORTRAN_UNBUFFERED_xx.
FWIW this option apparently is not even implemented, so whatever
we do can't break things for people.
Gr.
Steven