From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30368 invoked by alias); 15 Jan 2019 21:38:05 -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 30274 invoked by uid 89); 15 Jan 2019 21:38:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=apps, sophisticated, contrast, H*r:2a01 X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Jan 2019 21:38:03 +0000 Received: by mail-wm1-f68.google.com with SMTP id f188so4767106wmf.5 for ; Tue, 15 Jan 2019 13:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lNwJwUUcbbEBgGGNvBe020YlY99WKJ4R6tW2wSsYYi0=; b=g3pHymjdeMYVuokMTnvtp5Eq/Q1qM24L9TQY55aKxr3Ubh0mPuqxgeoA7xOMGUNxLX mUKolayUvXxhBJE/kp6VKMZ+xTmzgfn6O1nPdPbF6sI3ud0kPVgPprYmW7CRAi07SnLN 5N9Yk6KJtvN/vw3ZcpEcC+78uiVHsczLbiPEWHntdh1R4GoFl6NWcEyk2tWRhhlmJo/t 7HOYmZC+nskVByd5qUl6WGqSUc1fnjlKmCeoTFHBz0Zcq+jbkcZYrFp0dWZSnyRTnEwH b2FREcnzV1fGk1utNYWK6LzjAHZHS6tRhbURTr8vzEVW0IXuw54FRNX20kHWk1qMalcU mxZA== Return-Path: Received: from jozef-kubuntu ([2a01:4b00:87fd:900:41c3:74c8:e72:9656]) by smtp.gmail.com with ESMTPSA id j3sm31779617wmb.39.2019.01.15.13.38.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 15 Jan 2019 13:38:00 -0800 (PST) Date: Tue, 15 Jan 2019 21:38:00 -0000 From: Jozef Lawrynowicz To: Corinna Vinschen Cc: newlib@sourceware.org Subject: Re: [PATCH] Remove matherr, and SVID and X/Open math library configurations Message-ID: <20190115213318.7c27c68f@jozef-kubuntu> In-Reply-To: <20181214123147.4513b425@jozef-Aspire-VN7-793G> References: <20181211220807.72718758@jozef-Aspire-VN7-793G> <20181213125629.GI3972@calimero.vinschen.de> <20181214123147.4513b425@jozef-Aspire-VN7-793G> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2019/txt/msg00021.txt.bz2 Hi Corinna, Did you have any thoughts on my proposals detailed below? Thanks, Jozef On Fri, 14 Dec 2018 12:31:47 +0000 Jozef Lawrynowicz wrote: > Hi Corinna, > > Thanks for the feedback. > > On Thu, 13 Dec 2018 13:56:29 +0100 > Corinna Vinschen wrote: > > > We have to keep matherr as exported symbol from Cygwin to maintain > > backward compatibility. In contrast to embedded, we can't afford > > applications using this function to stop working with a new Cygwin > > release just because there's no matherr symbol anymore. > > I believe matherr is designed to only be called from the > floating-point arithmetic functions in the library, so if the > definition of matherr is removed along with all the uses of matherr, > users would still be able to link their applications. > > > So, would it be feasible to convert the matherr functions to a stub > > which just returns 0 and otherwise just go ahead? I'm pretty fuzzy > > on the implications this change has on old apps actually using > > matherr... > > The default matherr is already a stub and will always return 0, the > problem would be if the users' application code defines a more > sophisticated matherr which might fix up or report errors at runtime. > If they expect their customized matherr to be called after a > floating-point arithmetic error, then that will not happen anymore. > > Since the default matherr is a stub, and the default libm > configuration is X/Open, the default behaviour is actually identical > to POSIX libm. > > If we want application code with a customized matherr implementation > to fail to build, we can add a bad prototype for matherr to math.h. > So when users define their own matherr which uses the (old) correct > declaration, they will see an error: > > > sqrt.c:4:5: error: conflicting types for 'matherr' > > 4 | int matherr (struct exception *e) > > | ^~~~~~~ > > In file included from sqrt.c:1: > > /usr/local/msp430-elf/include/math.h:571:12: note: previous > > declaration of 'matherr' was here 571 | extern int matherr (void * > > MATHERR_ERROR_HANDLING_IS_OBSOLETE, int x); | ^~~~~~~ > > So I think we have only two choices: > 1. Remove matherr completely (this is what the submitted patch does) > Code which uses a customized matherr will build successfully > But the customized matherr will never be called at runtime > 2. Remove all usage of matherr, but give matherr a different > prototype to what is expected > Application code with a customized matherr will fail to build > > It's also worth noting that since the previous default libm > configuration was X/Open, errno was set correctly. The new default is > IEEE, so errno does not get set. The only other configuration now > available is POSIX, which sets errno correctly. If we are concerned > about backwards compatibility, then perhaps for Cygwin the default > libm configuration should be POSIX, so errno still gets set. > > What do you think is the best way forward? > > Jozef