From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66495 invoked by alias); 8 Aug 2019 15:51:31 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 66486 invoked by uid 89); 8 Aug 2019 15:51:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,HTML_MESSAGE autolearn=ham version=3.3.1 spammy=HX-Languages-Length:4461, H*c:alternative X-HELO: mx.coeval.ca Received: from mx.coeval.ca (HELO mx.coeval.ca) (184.75.211.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 15:51:29 +0000 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.coeval.ca (Postfix) with ESMTPSA id 6CF29436054 for ; Thu, 8 Aug 2019 15:51:27 +0000 (UTC) Received: by mail-ot1-f52.google.com with SMTP id x21so27205223otq.12 for ; Thu, 08 Aug 2019 08:51:27 -0700 (PDT) MIME-Version: 1.0 References: <1565277057-20621-1-git-send-email-joel@rtems.org> <20190808153856.GK11632@calimero.vinschen.de> <20190808154231.GN11632@calimero.vinschen.de> In-Reply-To: <20190808154231.GN11632@calimero.vinschen.de> Reply-To: joel@rtems.org From: Joel Sherrill Date: Thu, 08 Aug 2019 15:51:00 -0000 Message-ID: Subject: Re: [PATCH v5 2/3] Add default implementation of fenv.h and all methods To: Newlib , Joel Sherrill Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00440.txt.bz2 No problem. This needs to be cross-platform and a good foundation to layer architecture specific implementations. I changed the name and made the storage static which seems more appropriate. Version 5007 coming shortly. :) On Thu, Aug 8, 2019 at 10:42 AM Corinna Vinschen wrote: > 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 >