On Aug  8 17:38, Corinna Vinschen wrote:
> Hi Joel,
> 
> I just noticed another problem in terms of using this (partially)
> with Cygwin:
> 
> On Aug  8 10:10, joel@rtems.org wrote:
> > + * NOTE: The extern'ed variable fe_default_env_p is an implementation
> > + *       detail of this stub.  FE_DFL_ENV must point to an instance of
> > + *       fenv_t with the default fenv_t. The format of fenv_t and where
> > + *       FE_DFL_ENV is are implementation specific.
> > + */
> > +extern const fenv_t *fe_dfl_env_p;
> 
> Can we please rename this pointer to _fe_dfl_env, as it's already
> defined in Cygwin?  The reason is that this pointer is exported
> into user space via ...
> 
> > +#define FE_DFL_ENV fe_dfl_env_p
> 
> If you change the name here, Cygwin will not be able to use
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Make that "If you don't use the _fe_dfl_env name here..."

> > diff --git a/newlib/libm/fenv/fe_dfl_env.c b/newlib/libm/fenv/fe_dfl_env.c
> > [...]
> 
> this file as storage for the default environment so as not to break
> backward compatibility with existing executables.
> 
> > + * This is a non-functional implementation that should be overridden
> > + * by an architecture specific implementation in newlib/libm/machine/ARCH.
> > + *
> > + * The implmentation must defined FE_DFL_ENV to point to a default
> > + * environment of type fenv_t.
> > + */
> > +const fenv_t fe_dfl_env = { 0 };
> > +const fenv_t *fe_dfl_env_p = &fe_dfl_env;
> 
> The funny thing here is, that this file could be used by all targets,
> regardless of the definition of fenv_t, without the need to redefine it
> per target.  Only Cygwin couldn't.  It would have to provide it's own,
> even if the Cygwin code itself gets moved to i386 and x86_64, unless
> fe_dfl_env_p is renamed to _fe_dfl_env.


Sorry,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat