RFA: Add dummy fenv.h to libc/include
Nick Clifton
nickc@redhat.com
Tue Sep 25 15:58:00 GMT 2007
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
More information about the Newlib
mailing list