]> git.proxmox.com Git - mirror_edk2.git/blobdiff - AppPkg/Applications/Python/Python-2.7.2/Include/pyfpe.h
edk2: Remove AppPkg, StdLib, StdLibPrivateInternalFiles
[mirror_edk2.git] / AppPkg / Applications / Python / Python-2.7.2 / Include / pyfpe.h
diff --git a/AppPkg/Applications/Python/Python-2.7.2/Include/pyfpe.h b/AppPkg/Applications/Python/Python-2.7.2/Include/pyfpe.h
deleted file mode 100644 (file)
index 4da66ef..0000000
+++ /dev/null
@@ -1,176 +0,0 @@
-#ifndef Py_PYFPE_H\r
-#define Py_PYFPE_H\r
-#ifdef __cplusplus\r
-extern "C" {\r
-#endif\r
-/*\r
-     ---------------------------------------------------------------------  \r
-    /                       Copyright (c) 1996.                           \ \r
-   |          The Regents of the University of California.                 |\r
-   |                        All rights reserved.                           |\r
-   |                                                                       |\r
-   |   Permission to use, copy, modify, and distribute this software for   |\r
-   |   any purpose without fee is hereby granted, provided that this en-   |\r
-   |   tire notice is included in all copies of any software which is or   |\r
-   |   includes  a  copy  or  modification  of  this software and in all   |\r
-   |   copies of the supporting documentation for such software.           |\r
-   |                                                                       |\r
-   |   This  work was produced at the University of California, Lawrence   |\r
-   |   Livermore National Laboratory under  contract  no.  W-7405-ENG-48   |\r
-   |   between  the  U.S.  Department  of  Energy and The Regents of the   |\r
-   |   University of California for the operation of UC LLNL.              |\r
-   |                                                                       |\r
-   |                              DISCLAIMER                               |\r
-   |                                                                       |\r
-   |   This  software was prepared as an account of work sponsored by an   |\r
-   |   agency of the United States Government. Neither the United States   |\r
-   |   Government  nor the University of California nor any of their em-   |\r
-   |   ployees, makes any warranty, express or implied, or  assumes  any   |\r
-   |   liability  or  responsibility  for the accuracy, completeness, or   |\r
-   |   usefulness of any information,  apparatus,  product,  or  process   |\r
-   |   disclosed,   or  represents  that  its  use  would  not  infringe   |\r
-   |   privately-owned rights. Reference herein to any specific  commer-   |\r
-   |   cial  products,  process,  or  service  by trade name, trademark,   |\r
-   |   manufacturer, or otherwise, does not  necessarily  constitute  or   |\r
-   |   imply  its endorsement, recommendation, or favoring by the United   |\r
-   |   States Government or the University of California. The views  and   |\r
-   |   opinions  of authors expressed herein do not necessarily state or   |\r
-   |   reflect those of the United States Government or  the  University   |\r
-   |   of  California,  and shall not be used for advertising or product   |\r
-    \  endorsement purposes.                                              / \r
-     ---------------------------------------------------------------------  \r
-*/\r
-\r
-/*\r
- *       Define macros for handling SIGFPE.\r
- *       Lee Busby, LLNL, November, 1996\r
- *       busby1@llnl.gov\r
- * \r
- *********************************************\r
- * Overview of the system for handling SIGFPE:\r
- * \r
- * This file (Include/pyfpe.h) defines a couple of "wrapper" macros for\r
- * insertion into your Python C code of choice. Their proper use is\r
- * discussed below. The file Python/pyfpe.c defines a pair of global\r
- * variables PyFPE_jbuf and PyFPE_counter which are used by the signal\r
- * handler for SIGFPE to decide if a particular exception was protected\r
- * by the macros. The signal handler itself, and code for enabling the\r
- * generation of SIGFPE in the first place, is in a (new) Python module\r
- * named fpectl. This module is standard in every respect. It can be loaded\r
- * either statically or dynamically as you choose, and like any other\r
- * Python module, has no effect until you import it.\r
- * \r
- * In the general case, there are three steps toward handling SIGFPE in any\r
- * Python code:\r
- * \r
- * 1) Add the *_PROTECT macros to your C code as required to protect\r
- *    dangerous floating point sections.\r
- * \r
- * 2) Turn on the inclusion of the code by adding the ``--with-fpectl''\r
- *    flag at the time you run configure.  If the fpectl or other modules\r
- *    which use the *_PROTECT macros are to be dynamically loaded, be\r
- *    sure they are compiled with WANT_SIGFPE_HANDLER defined.\r
- * \r
- * 3) When python is built and running, import fpectl, and execute\r
- *    fpectl.turnon_sigfpe(). This sets up the signal handler and enables\r
- *    generation of SIGFPE whenever an exception occurs. From this point\r
- *    on, any properly trapped SIGFPE should result in the Python\r
- *    FloatingPointError exception.\r
- * \r
- * Step 1 has been done already for the Python kernel code, and should be\r
- * done soon for the NumPy array package.  Step 2 is usually done once at\r
- * python install time. Python's behavior with respect to SIGFPE is not\r
- * changed unless you also do step 3. Thus you can control this new\r
- * facility at compile time, or run time, or both.\r
- * \r
- ******************************** \r
- * Using the macros in your code:\r
- * \r
- * static PyObject *foobar(PyObject *self,PyObject *args)\r
- * {\r
- *     ....\r
- *     PyFPE_START_PROTECT("Error in foobar", return 0)\r
- *     result = dangerous_op(somearg1, somearg2, ...);\r
- *     PyFPE_END_PROTECT(result)\r
- *     ....\r
- * }\r
- * \r
- * If a floating point error occurs in dangerous_op, foobar returns 0 (NULL),\r
- * after setting the associated value of the FloatingPointError exception to\r
- * "Error in foobar". ``Dangerous_op'' can be a single operation, or a block\r
- * of code, function calls, or any combination, so long as no alternate\r
- * return is possible before the PyFPE_END_PROTECT macro is reached.\r
- * \r
- * The macros can only be used in a function context where an error return\r
- * can be recognized as signaling a Python exception. (Generally, most\r
- * functions that return a PyObject * will qualify.)\r
- * \r
- * Guido's original design suggestion for PyFPE_START_PROTECT and\r
- * PyFPE_END_PROTECT had them open and close a local block, with a locally\r
- * defined jmp_buf and jmp_buf pointer. This would allow recursive nesting\r
- * of the macros. The Ansi C standard makes it clear that such local\r
- * variables need to be declared with the "volatile" type qualifier to keep\r
- * setjmp from corrupting their values. Some current implementations seem\r
- * to be more restrictive. For example, the HPUX man page for setjmp says\r
- * \r
- *   Upon the return from a setjmp() call caused by a longjmp(), the\r
- *   values of any non-static local variables belonging to the routine\r
- *   from which setjmp() was called are undefined. Code which depends on\r
- *   such values is not guaranteed to be portable.\r
- * \r
- * I therefore decided on a more limited form of nesting, using a counter\r
- * variable (PyFPE_counter) to keep track of any recursion.  If an exception\r
- * occurs in an ``inner'' pair of macros, the return will apparently\r
- * come from the outermost level.\r
- * \r
- */\r
-\r
-#ifdef WANT_SIGFPE_HANDLER\r
-#include <signal.h>\r
-#include <setjmp.h>\r
-#include <math.h>\r
-extern jmp_buf PyFPE_jbuf;\r
-extern int PyFPE_counter;\r
-extern double PyFPE_dummy(void *);\r
-\r
-#define PyFPE_START_PROTECT(err_string, leave_stmt) \\r
-if (!PyFPE_counter++ && setjmp(PyFPE_jbuf)) { \\r
-       PyErr_SetString(PyExc_FloatingPointError, err_string); \\r
-       PyFPE_counter = 0; \\r
-       leave_stmt; \\r
-}\r
-\r
-/*\r
- * This (following) is a heck of a way to decrement a counter. However,\r
- * unless the macro argument is provided, code optimizers will sometimes move\r
- * this statement so that it gets executed *before* the unsafe expression\r
- * which we're trying to protect.  That pretty well messes things up,\r
- * of course.\r
- * \r
- * If the expression(s) you're trying to protect don't happen to return a\r
- * value, you will need to manufacture a dummy result just to preserve the\r
- * correct ordering of statements.  Note that the macro passes the address\r
- * of its argument (so you need to give it something which is addressable).\r
- * If your expression returns multiple results, pass the last such result\r
- * to PyFPE_END_PROTECT.\r
- * \r
- * Note that PyFPE_dummy returns a double, which is cast to int.\r
- * This seeming insanity is to tickle the Floating Point Unit (FPU).\r
- * If an exception has occurred in a preceding floating point operation,\r
- * some architectures (notably Intel 80x86) will not deliver the interrupt\r
- * until the *next* floating point operation.  This is painful if you've\r
- * already decremented PyFPE_counter.\r
- */\r
-#define PyFPE_END_PROTECT(v) PyFPE_counter -= (int)PyFPE_dummy(&(v));\r
-\r
-#else\r
-\r
-#define PyFPE_START_PROTECT(err_string, leave_stmt)\r
-#define PyFPE_END_PROTECT(v)\r
-\r
-#endif\r
-\r
-#ifdef __cplusplus\r
-}\r
-#endif\r
-#endif /* !Py_PYFPE_H */\r