math_errhandling

05/03/2010 - 10:52 von Markus Wichmann | Report spam
Hi all,

eines vorweg: Ich habe keinen echten C-Standard hier, nur einen
C Standard Draft (vom 11. 8. 2008). Darum wollte ich mal nachfragen, ob
7.12 Abs. 9 neu hinzugekommen oder Teil von C99 ist. Der fragliche
Abschnitt lautet:

#v+
The macros
MATH_ERRNO
MATH_ERREXCEPT
expand to the integer constants 1 and 2, respectively; the macro
math_errhandling
expands to an expression that has type int and the value MATH_ERRNO,
MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling is
constant for the duration of the program. It is unspecified whether
math_errhandling is a macro or an identifier with external linkage. If a macro
definition is suppressed or a program defines an identifier with the name
math_errhandling, the behavior is undefined. If the expression
math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation
shall define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in
<fenv.h>.
#v-


Da verbleiben jetzt noch ein paar Fragen:

Also, math_errhandling ist für die Gesamtdauer des Programms konstant.
Das heißt, nicht das Programm sucht sich aus, ob es per errno oder
exception über Fehler benachrichtigt wird, sondern die C library. Ist
also folgende Implementierung standardkonform?

#define MATH_ERRNO 1
#define MATH_ERREXCEPT 2
#define math_errhandling 2

Und welchen Sinn hat es eigentlich, das so zu machen? Wàre es nicht
einfacher, zu sagen, eine Implementierung müsse MATH_ERRNO definieren,
wenn Fehler durch ein Setzen von errno angezeigt werden, und
MATH_ERREXCEPT wenn Fehler durch Floating Point Exceptions angezeigt
werden. Auf die Weise könnte man die Fehleranzeigemethode zur
Compile-Zeit bestimmen. So aber muss jede Anwendung die
Fehleranzeigemethode zur Laufzeit prüfen, wenn sie wissen will, was von
dem gerade erhaltenen Ergebnis zu halten ist.

Tschö,
Markus

Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart
terminals.

news://freenews.netfront.net/ - complaints: news@netfront.net
 

Lesen sie die antworten

#1 Stefan Reuther
05/03/2010 - 18:22 | Warnen spam
Hallo,

Markus Wichmann wrote:
The macros
MATH_ERRNO
MATH_ERREXCEPT
expand to the integer constants 1 and 2, respectively; the macro
math_errhandling
expands [...]



Das steht in C99 auch so drin.

Also, math_errhandling ist für die Gesamtdauer des Programms konstant.
Das heißt, nicht das Programm sucht sich aus, ob es per errno oder
exception über Fehler benachrichtigt wird, sondern die C library. Ist
also folgende Implementierung standardkonform?

#define MATH_ERRNO 1
#define MATH_ERREXCEPT 2
#define math_errhandling 2



Davon gehe ich mal aus.

Und welchen Sinn hat es eigentlich, das so zu machen? Wàre es nicht
einfacher, zu sagen, eine Implementierung müsse MATH_ERRNO definieren,
wenn Fehler durch ein Setzen von errno angezeigt werden, und
MATH_ERREXCEPT wenn Fehler durch Floating Point Exceptions angezeigt
werden. Auf die Weise könnte man die Fehleranzeigemethode zur
Compile-Zeit bestimmen.



Es gibt einen "Rationale" zu C99.
<http://www.open-std.org/jtc1/sc22/w...10.pdf>

Der sagt auf Seite 136: "An implementation might provide two versions of
the math library — one that uses errno as a means to indicate errors and
a second that uses the floating-point exceptions as error indicators.
Then, the user links in the version of the math library whose error
style matches their needs."

Dann haben beide Libraries eben ein 'int math_errhandling', das sagt,
wie es gerade funktioniert.

So aber muss jede Anwendung die Fehleranzeigemethode zur Laufzeit
prüfen, wenn sie wissen will, was von dem gerade erhaltenen Ergebnis
zu halten ist.



Wenn die Library 'math_errhandling' eine Konstante macht, optimiert der
Compiler den nicht genommenen Zweig weg. Und wenn nicht, dann werden
sich vermutlich die Compilernutzer beim Hersteller beschweren, er solle
eine Library bauen, die ihnen schnellere Programme ermöglicht :-)


Stefan

Ähnliche fragen