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

[Nick Clifton <nickc at redhat dot com>]

Hi Corinna,

> Consider an application which configure script checks for the existence
> of the fenv.h header and functions defined therein.  It will find that
> the header exists and that, for instance, the function fesetround
> exists, too.  However, the fesetround will always return -1.  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."

So if the dummy version returns zero, then the calling application has the 
right to assume that any floating point arithmetic from now on will use the 
rounding mode just set.  Since these functions do not actually influence any 
floating point behaviour at all, it is a violation of the ISO C99 standard to 
claim that they do.

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


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 ?

Cheers
  Nick