[Python-checkins] cpython (3.5): remove trailing whitespace

Tue Sep 20 01:17:57 EDT 2016

https://hg.python.org/cpython/rev/98d1788c905c
changeset: 103961:98d1788c905c
branch: 3.5
parent: 103958:7844a46225a2
user: Benjamin Peterson <benjamin at python.org>
date: Mon Sep 19 22:16:36 2016 -0700
summary:
 remove trailing whitespace
files:
 Include/pyfpe.h | 36 +++++++++++++++---------------
 Include/pyport.h | 2 +-
 Misc/coverity_model.c | 2 +-
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/Include/pyfpe.h b/Include/pyfpe.h
--- a/Include/pyfpe.h
+++ b/Include/pyfpe.h
@@ -45,10 +45,10 @@
 * Define macros for handling SIGFPE.
 * Lee Busby, LLNL, November, 1996
 * busby1 at llnl.gov
- * 
+ *
 *********************************************
 * Overview of the system for handling SIGFPE:
- * 
+ *
 * This file (Include/pyfpe.h) defines a couple of "wrapper" macros for
 * insertion into your Python C code of choice. Their proper use is
 * discussed below. The file Python/pyfpe.c defines a pair of global
@@ -59,33 +59,33 @@
 * named fpectl. This module is standard in every respect. It can be loaded
 * either statically or dynamically as you choose, and like any other
 * Python module, has no effect until you import it.
- * 
+ *
 * In the general case, there are three steps toward handling SIGFPE in any
 * Python code:
- * 
+ *
 * 1) Add the *_PROTECT macros to your C code as required to protect
 * dangerous floating point sections.
- * 
+ *
 * 2) Turn on the inclusion of the code by adding the ``--with-fpectl''
 * flag at the time you run configure. If the fpectl or other modules
 * which use the *_PROTECT macros are to be dynamically loaded, be
 * sure they are compiled with WANT_SIGFPE_HANDLER defined.
- * 
+ *
 * 3) When python is built and running, import fpectl, and execute
 * fpectl.turnon_sigfpe(). This sets up the signal handler and enables
 * generation of SIGFPE whenever an exception occurs. From this point
 * on, any properly trapped SIGFPE should result in the Python
 * FloatingPointError exception.
- * 
+ *
 * Step 1 has been done already for the Python kernel code, and should be
 * done soon for the NumPy array package. Step 2 is usually done once at
 * python install time. Python's behavior with respect to SIGFPE is not
 * changed unless you also do step 3. Thus you can control this new
 * facility at compile time, or run time, or both.
- * 
- ******************************** 
+ *
+ ********************************
 * Using the macros in your code:
- * 
+ *
 * static PyObject *foobar(PyObject *self,PyObject *args)
 * {
 * ....
@@ -94,17 +94,17 @@
 * PyFPE_END_PROTECT(result)
 * ....
 * }
- * 
+ *
 * If a floating point error occurs in dangerous_op, foobar returns 0 (NULL),
 * after setting the associated value of the FloatingPointError exception to
 * "Error in foobar". ``Dangerous_op'' can be a single operation, or a block
 * of code, function calls, or any combination, so long as no alternate
 * return is possible before the PyFPE_END_PROTECT macro is reached.
- * 
+ *
 * The macros can only be used in a function context where an error return
 * can be recognized as signaling a Python exception. (Generally, most
 * functions that return a PyObject * will qualify.)
- * 
+ *
 * Guido's original design suggestion for PyFPE_START_PROTECT and
 * PyFPE_END_PROTECT had them open and close a local block, with a locally
 * defined jmp_buf and jmp_buf pointer. This would allow recursive nesting
@@ -112,17 +112,17 @@
 * variables need to be declared with the "volatile" type qualifier to keep
 * setjmp from corrupting their values. Some current implementations seem
 * to be more restrictive. For example, the HPUX man page for setjmp says
- * 
+ *
 * Upon the return from a setjmp() call caused by a longjmp(), the
 * values of any non-static local variables belonging to the routine
 * from which setjmp() was called are undefined. Code which depends on
 * such values is not guaranteed to be portable.
- * 
+ *
 * I therefore decided on a more limited form of nesting, using a counter
 * variable (PyFPE_counter) to keep track of any recursion. If an exception
 * occurs in an ``inner'' pair of macros, the return will apparently
 * come from the outermost level.
- * 
+ *
 */
 
 #ifdef WANT_SIGFPE_HANDLER
@@ -146,14 +146,14 @@
 * this statement so that it gets executed *before* the unsafe expression
 * which we're trying to protect. That pretty well messes things up,
 * of course.
- * 
+ *
 * If the expression(s) you're trying to protect don't happen to return a
 * value, you will need to manufacture a dummy result just to preserve the
 * correct ordering of statements. Note that the macro passes the address
 * of its argument (so you need to give it something which is addressable).
 * If your expression returns multiple results, pass the last such result
 * to PyFPE_END_PROTECT.
- * 
+ *
 * Note that PyFPE_dummy returns a double, which is cast to int.
 * This seeming insanity is to tickle the Floating Point Unit (FPU).
 * If an exception has occurred in a preceding floating point operation,
diff --git a/Include/pyport.h b/Include/pyport.h
--- a/Include/pyport.h
+++ b/Include/pyport.h
@@ -886,7 +886,7 @@
 #define PY_LITTLE_ENDIAN 1
 #endif
 
-#ifdef Py_BUILD_CORE 
+#ifdef Py_BUILD_CORE
 /*
 * Macros to protect CRT calls against instant termination when passed an
 * invalid parameter (issue23524).
diff --git a/Misc/coverity_model.c b/Misc/coverity_model.c
--- a/Misc/coverity_model.c
+++ b/Misc/coverity_model.c
@@ -140,7 +140,7 @@
 build_struct_time(int y, int m, int d, int hh, int mm, int ss, int dstflag)
 {
 PyObject *result;
- 
+
 __coverity_tainted_data_sanitize__(y);
 __coverity_tainted_data_sanitize__(m);
 __coverity_tainted_data_sanitize__(d);
-- 
Repository URL: https://hg.python.org/cpython
