Re: RFA: Add dummy fenv.h to libc/include

[Corinna Vinschen <vinschen at redhat dot com>]

Hi Nick,

On Sep 25 16:14, Nick Clifton wrote:
> Hi Corinna,
> 
> >Consider an application which configure script checks for the existence
> >of the fenv.h header and functions defined therein.  [...] This might
> >result in some applications not being buildable anymore in a working
> >way.
> 
> Hmm, yes I suppose that this could happen.
> 
> >Wouldn't it be better to fake the "set"-type functions to always succeed?
> 
> No.  Having these functions succeed when in fact they are not really doing 
> anything would actually violate the ISO C99 specification.  For example the 
> spec for fesetround() says:
> 
>    "The fesetround function returns zero if and only if the
>      requested rounding direction was established."

ACK

> >Or, to drop the definitions of the set functions entirely?
> 
> Dropping them would be less than ideal, since it would stop ISO C99 
> conformance tests from working.  (If the fenv.h header file exists, then 
> the conformance tests would be correct in assuming that the set- type 
> functions exists and can be linked).

ACK

> Question - is it better to face the slings and arrow of outrageous fortune 
> or ... err, sorry, wrong question.  Question - is it better to have a dummy 
> fenv.h that conforms to the spec but tells any application using it that 
> the some of the functions have not succeeded in their appointed task, or is 
> it better to not have an fenv.h and to leave newlib's ISO C99 compliance 
> (in this area) to when individual targets implement these features ?
> 
> I think that maybe the best compromise would be to take the proposed fenv.h 
> as it is, but to add a define, eg __NEWLIB_DUMMY_FENV_H which can be looked 
> for by applications that might be caught out by the dummy functions.  What 
> do you think ?

After reading the description of the fenv.h header in SUSv3, I think
that providing the header w/o actually providing the functionality
is also a violation of the standard.  The spec for fenv.h contains
wording like:

  "The <fenv.h> header shall define the following constants if and only
  if the implementation supports the floating-point exception by means
  of the floating-point functions [...]"

  "The <fenv.h> header shall define the following constants if and only
  if the implementation supports getting and setting the represented
  rounding direction by means of the fegetround() and fesetround()
  functions"

Note the usage of "if and only if".

Providing the __NEWLIB_DUMMY_FENV_H is also non-standard and doesn't
help conforming applications which test for the fenv.h header.  How are
they supposed to know that they should check for that macro?

The bottom line is, wouldn't it be better to add the dummy header only
to the testsuite which needs this file to run specific tests, rather
than creating a dummy file which affects all newlib targets and might
result in spurious run-time failures?

But that's just me.  If others think that adding fenv.h is a good idea,
it's ok with me.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat