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

[Jozef Lawrynowicz]

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 <jozef.l@mittosystems.com> wrote:

> Hi Corinna,
> 
> Thanks for the feedback.
> 
> On Thu, 13 Dec 2018 13:56:29 +0100
> Corinna Vinschen <vinschen@redhat.com> 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