@@ -45,10 +45,10 @@ extern "C" {
4545 * Define macros for handling SIGFPE.
4646 * Lee Busby, LLNL, November, 1996
4747 * busby1@llnl.gov
48- *
48+ *
4949 *********************************************
5050 * Overview of the system for handling SIGFPE:
51- *
51+ *
5252 * This file (Include/pyfpe.h) defines a couple of "wrapper" macros for
5353 * insertion into your Python C code of choice. Their proper use is
5454 * discussed below. The file Python/pyfpe.c defines a pair of global
@@ -59,33 +59,33 @@ extern "C" {
5959 * named fpectl. This module is standard in every respect. It can be loaded
6060 * either statically or dynamically as you choose, and like any other
6161 * Python module, has no effect until you import it.
62- *
62+ *
6363 * In the general case, there are three steps toward handling SIGFPE in any
6464 * Python code:
65- *
65+ *
6666 * 1) Add the *_PROTECT macros to your C code as required to protect
6767 * dangerous floating point sections.
68- *
68+ *
6969 * 2) Turn on the inclusion of the code by adding the ``--with-fpectl''
7070 * flag at the time you run configure. If the fpectl or other modules
7171 * which use the *_PROTECT macros are to be dynamically loaded, be
7272 * sure they are compiled with WANT_SIGFPE_HANDLER defined.
73- *
73+ *
7474 * 3) When python is built and running, import fpectl, and execute
7575 * fpectl.turnon_sigfpe(). This sets up the signal handler and enables
7676 * generation of SIGFPE whenever an exception occurs. From this point
7777 * on, any properly trapped SIGFPE should result in the Python
7878 * FloatingPointError exception.
79- *
79+ *
8080 * Step 1 has been done already for the Python kernel code, and should be
8181 * done soon for the NumPy array package. Step 2 is usually done once at
8282 * python install time. Python's behavior with respect to SIGFPE is not
8383 * changed unless you also do step 3. Thus you can control this new
8484 * facility at compile time, or run time, or both.
85- *
86- ********************************
85+ *
86+ ********************************
8787 * Using the macros in your code:
88- *
88+ *
8989 * static PyObject *foobar(PyObject *self,PyObject *args)
9090 * {
9191 * ....
@@ -94,35 +94,35 @@ extern "C" {
9494 * PyFPE_END_PROTECT(result)
9595 * ....
9696 * }
97- *
97+ *
9898 * If a floating point error occurs in dangerous_op, foobar returns 0 (NULL),
9999 * after setting the associated value of the FloatingPointError exception to
100100 * "Error in foobar". ``Dangerous_op'' can be a single operation, or a block
101101 * of code, function calls, or any combination, so long as no alternate
102102 * return is possible before the PyFPE_END_PROTECT macro is reached.
103- *
103+ *
104104 * The macros can only be used in a function context where an error return
105105 * can be recognized as signaling a Python exception. (Generally, most
106106 * functions that return a PyObject * will qualify.)
107- *
107+ *
108108 * Guido's original design suggestion for PyFPE_START_PROTECT and
109109 * PyFPE_END_PROTECT had them open and close a local block, with a locally
110110 * defined jmp_buf and jmp_buf pointer. This would allow recursive nesting
111111 * of the macros. The Ansi C standard makes it clear that such local
112112 * variables need to be declared with the "volatile" type qualifier to keep
113113 * setjmp from corrupting their values. Some current implementations seem
114114 * to be more restrictive. For example, the HPUX man page for setjmp says
115- *
115+ *
116116 * Upon the return from a setjmp() call caused by a longjmp(), the
117117 * values of any non-static local variables belonging to the routine
118118 * from which setjmp() was called are undefined. Code which depends on
119119 * such values is not guaranteed to be portable.
120- *
120+ *
121121 * I therefore decided on a more limited form of nesting, using a counter
122122 * variable (PyFPE_counter) to keep track of any recursion. If an exception
123123 * occurs in an ``inner'' pair of macros, the return will apparently
124124 * come from the outermost level.
125- *
125+ *
126126 */
127127
128128#ifdef WANT_SIGFPE_HANDLER
@@ -146,14 +146,14 @@ if (!PyFPE_counter++ && setjmp(PyFPE_jbuf)) { \
146146 * this statement so that it gets executed *before* the unsafe expression
147147 * which we're trying to protect. That pretty well messes things up,
148148 * of course.
149- *
149+ *
150150 * If the expression(s) you're trying to protect don't happen to return a
151151 * value, you will need to manufacture a dummy result just to preserve the
152152 * correct ordering of statements. Note that the macro passes the address
153153 * of its argument (so you need to give it something which is addressable).
154154 * If your expression returns multiple results, pass the last such result
155155 * to PyFPE_END_PROTECT.
156- *
156+ *
157157 * Note that PyFPE_dummy returns a double, which is cast to int.
158158 * This seeming insanity is to tickle the Floating Point Unit (FPU).
159159 * If an exception has occurred in a preceding floating point operation,
0 commit comments