Mail Archives: djgpp-workers/2003/08/28/18:35:19
Hello.
Eli Zaretskii wrote:
>
> > Date: Thu, 28 Aug 2003 09:38:57 -0500
> > From: Eric Rudd <rudd AT cyberoptics DOT com>
[snip]
> > Part of the problem is that C99 never satisfactorily defines
> > "exception". Reading between the lines in footnote 178 in clause 7.6.2.2
> > (bear in mind that the footnotes are informative, not normative), it
> > appears that "exception" is intended to be an FPU processor exception,
> > as described by Intel, but I've searched in vain for a normative
> > definition. Of course, C99 can't talk about processor specifics; it
> > would instead talk of the consequences of the exception visible to the
> > program.
>
> It might be a good idea to see what does glibc do on GNU/Linux
> systems. If one runs a program there that calls asin(2.0), what
> happens? Does it crash? does it raise SIGFPE? can you catch the
> signal? something else?
Below is what happens on my Redhat Linux 6.2 box. I don't have access to
Redhat 8, but someone should test with that too, since it has a newer (i.e.:
more C99-ish?) glibc.
iolanthe:~/src/tmp =] rpm -q glibc
glibc-2.1.3-28
iolanthe:~/src/tmp =] cat t-asin.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int
main (void)
{
printf("%f\n", asin(2.0));
return EXIT_SUCCESS;
}
iolanthe:~/src/tmp =] gcc -g -Wall -o t-asin t-asin.c -lm
iolanthe:~/src/tmp =] ./t-asin
nan
NB: no SIGFPE.
> > The material in Annex F needs to be implemented only if __STDC_IEC_559__
> > is defined.
>
> Does glibc define this in any of its headers?
Yes. It's defined in <features.h>, which is one of glibc's headers:
iolanthe:~/src/tmp =] find /usr/include -name '*.h' | xargs grep
__STDC_IEC_559__
/usr/include/features.h:#define __STDC_IEC_559__ 1
iolanthe:~/src/tmp =] rpm -qf /usr/include/features.h
glibc-devel-2.1.3-28
> > Whether it is worthwhile (or even desirable) to re-write the existing
> > math routines to comply with IEC 60559/Annex F is another matter
> > entirely.
>
> I'd say we cannot afford such a massive rewrite. Neither libc.a nor
> libm.a, as we have them, don't produce SIGFPE; on the contrary, they
> go to great lengths to avoid that.
I don't think anyone has the time to rewrite the maths library.
BTW I think you've got too many negatives above. Should it be:
"Neither libc.a nor libm.a, as we have them, produce SIGFPE; on the contrary,
they go to great lengths to avoid that."
(Think of it as: "libc.a and libm.a don't produce SIGFPE;...")
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -