Re: [PATCH] Remove matherr, and SVID and X/Open math library configurations

Corinna Vinschen <[email protected]> Sat, 15 Dec 2018 13:51:29 +0100
Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>
On Dec 14 12:31, Jozef Lawrynowicz wrote:
> Hi Corinna,
> 
> Thanks for the feedback.
> 
> On Thu, 13 Dec 2018 13:56:29 +0100
> Corinna Vinschen <[email protected]> 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.

No, that doesn't work.  Keep in mind that Cygwin is running on Windows.
The matherr symbols has been exported from the DLL.  If an application
uses this function and has been linked against the Cygwin DLL, this
application will fail to run on a newer Cygwin not exporting this
symbol, because the Windows Loader will fail to resolve a symbol at
executable load time.

I know, SVID defines the usage differently, but Cygwin *has* to continue
exporting the symbol, even if we remove it for any other target in newlib.

> > 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.

This isn't a problem on Cygwin since C library function overloads
don't work on PE/COFF they way they do on ELF targets.

On second thought, this also means the chance there actually *is* a
Cygwin executable using the pre-defined function or defining its own,
working matherr is almost nil.


> Since the default matherr is a stub, and the default libm configuration is
> X/Open, the default behaviour is actually identical to POSIX libm.

So, sounds like we can just keep a (Cygwin-only) matherr which just
returns 0 to maintain backward compat in a border case.

> 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:

I don't know.  I guess we should just drop the prototype and be done
with it.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
signature.asc (application/pgp-signature, 833 B)