mirrors/cpython
0
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2024-11-25 10:54:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
11ee90289c
cpython/Include/pythonrun.h

140 lines
4.8 KiB
C
Raw Normal View History

Added copyright notice.
1991-02-19 20:39:46 +08:00
"Compiling" version
1990-12-20 23:06:42 +08:00
/* Interfaces to parse and execute pieces of python code */
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
#ifndef Py_PYTHONRUN_H
#define Py_PYTHONRUN_H
#ifdef __cplusplus
extern "C" {
#endif
Part way to allowing "from __future__ import generators" to communicate that info to code dynamically compiled *by* code compiled with generators enabled. Doesn't yet work because there's still no way to tell the parser that "yield" is OK (unlike nested_scopes, the parser has its fingers in this too). Replaced PyEval_GetNestedScopes by a more-general PyEval_MergeCompilerFlags. Perhaps I should not have? I doubted it was *intended* to be part of the public API, so just did.
2001-07-16 10:29:45 +08:00
/* These flags are named after the __future__ statements that introduced
them. May not remain true for later additions, so fiddle this comment
accordingly then. */
#define PyCF_NESTED_SCOPES (0x00000001UL)
#define PyCF_GENERATORS (0x00000002UL)
Implement PEP 238 in its (almost) full glory. This introduces: - A new operator // that means floor division (the kind of division where 1/2 is 0). - The "future division" statement ("from __future__ import division) which changes the meaning of the / operator to implement "true division" (where 1/2 is 0.5). - New overloadable operators __truediv__ and __floordiv__. - New slots in the PyNumberMethods struct for true and floor division, new abstract APIs for them, new opcodes, and so on. I emphasize that without the future division statement, the semantics of / will remain unchanged until Python 3.0. Not yet implemented are warnings (default off) when / is used with int or long arguments. This has been on display since 7/31 as SF patch #443474. Flames to /dev/null.
2001-08-08 13:00:18 +08:00
#define PyCF_DIVISION (0x00000004UL)
Useful future statement support for the interactive interpreter (Also remove warning about module-level global decl, because we can't distinguish from code passed to exec.) Define PyCompilerFlags type contains a single element, cf_nested_scopes, that is true if a nested scopes future statement has been entered at the interactive prompt. New API functions: PyNode_CompileFlags() PyRun_InteractiveOneFlags() -- same as their non Flags counterparts except that the take an optional PyCompilerFlags pointer compile.c: In jcompile() use PyCompilerFlags argument. If cf_nested_scopes is true, compile code with nested scopes. If it is false, but the code has a valid future nested scopes statement, set it to true. pythonrun.c: Create a new PyCompilerFlags object in PyRun_InteractiveLoop() and thread it through to PyRun_InteractiveOneFlags().
2001-03-02 06:59:14 +08:00
typedef struct {
Part way to allowing "from __future__ import generators" to communicate that info to code dynamically compiled *by* code compiled with generators enabled. Doesn't yet work because there's still no way to tell the parser that "yield" is OK (unlike nested_scopes, the parser has its fingers in this too). Replaced PyEval_GetNestedScopes by a more-general PyEval_MergeCompilerFlags. Perhaps I should not have? I doubted it was *intended* to be part of the public API, so just did.
2001-07-16 10:29:45 +08:00
unsigned long cf_flags; /* bitmask of PyCF_xxx flags */
Useful future statement support for the interactive interpreter (Also remove warning about module-level global decl, because we can't distinguish from code passed to exec.) Define PyCompilerFlags type contains a single element, cf_nested_scopes, that is true if a nested scopes future statement has been entered at the interactive prompt. New API functions: PyNode_CompileFlags() PyRun_InteractiveOneFlags() -- same as their non Flags counterparts except that the take an optional PyCompilerFlags pointer compile.c: In jcompile() use PyCompilerFlags argument. If cf_nested_scopes is true, compile code with nested scopes. If it is false, but the code has a valid future nested scopes statement, set it to true. pythonrun.c: Create a new PyCompilerFlags object in PyRun_InteractiveLoop() and thread it through to PyRun_InteractiveOneFlags().
2001-03-02 06:59:14 +08:00
} PyCompilerFlags;
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) Py_SetProgramName(char *);
DL_IMPORT(char *) Py_GetProgramName(void);
Added declarations for Py_{Set,Get}ProgramName() and a bunch of other Py_Get*() functions.
1997-07-20 03:50:52 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) Py_SetPythonHome(char *);
DL_IMPORT(char *) Py_GetPythonHome(void);
- Add Py_GetPythonHome() and Py_SetPythonHome(), intended to allow embedders to force a different PYTHONHOME. - Add new interface PyErr_PrintEx(flag); same as PyErr_Print() but flag determines whether sys.last_* are set or not. PyErr_Print() now simply calls PyErr_PrintEx(1).
1998-02-07 06:28:05 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) Py_Initialize(void);
DL_IMPORT(void) Py_Finalize(void);
DL_IMPORT(int) Py_IsInitialized(void);
DL_IMPORT(PyThreadState *) Py_NewInterpreter(void);
DL_IMPORT(void) Py_EndInterpreter(PyThreadState *);
"Compiling" version
1990-12-20 23:06:42 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) PyRun_AnyFile(FILE *, char *);
Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), PyRun_FileEx(). These are the same as their non-Ex counterparts but have an extra argument, a flag telling them to close the file when done. Then this is used by Py_Main() and execfile() to close the file after it is parsed but before it is executed. Adding APIs seems strange given the feature freeze but it's the only way I see to close the bug report without incompatible changes. [ Bug #110616 ] source file stays open after parsing is done (PR#209)
2000-08-28 03:21:52 +08:00
DL_IMPORT(int) PyRun_AnyFileEx(FILE *, char *, int);
"Compiling" version
1990-12-20 23:06:42 +08:00
Extend support for from __future__ import nested_scopes If a module has a future statement enabling nested scopes, they are also enable for the exec statement and the functions compile() and execfile() if they occur in the module. If Python is run with the -i option, which enters interactive mode after executing a script, and the script it runs enables nested scopes, they are also enabled in interactive mode. XXX The use of -i with -c "from __future__ import nested_scopes" is not supported. What's the point? To support these changes, many function variants have been added to pythonrun.c. All the variants names end with Flags and they take an extra PyCompilerFlags * argument. It is possible that this complexity will be eliminated in a future version of the interpreter in which nested scopes are not optional.
2001-03-22 10:47:58 +08:00
DL_IMPORT(int) PyRun_AnyFileFlags(FILE *, char *, PyCompilerFlags *);
DL_IMPORT(int) PyRun_AnyFileExFlags(FILE *, char *, int, PyCompilerFlags *);
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) PyRun_SimpleString(char *);
DL_IMPORT(int) PyRun_SimpleFile(FILE *, char *);
Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), PyRun_FileEx(). These are the same as their non-Ex counterparts but have an extra argument, a flag telling them to close the file when done. Then this is used by Py_Main() and execfile() to close the file after it is parsed but before it is executed. Adding APIs seems strange given the feature freeze but it's the only way I see to close the bug report without incompatible changes. [ Bug #110616 ] source file stays open after parsing is done (PR#209)
2000-08-28 03:21:52 +08:00
DL_IMPORT(int) PyRun_SimpleFileEx(FILE *, char *, int);
Extend support for from __future__ import nested_scopes If a module has a future statement enabling nested scopes, they are also enable for the exec statement and the functions compile() and execfile() if they occur in the module. If Python is run with the -i option, which enters interactive mode after executing a script, and the script it runs enables nested scopes, they are also enabled in interactive mode. XXX The use of -i with -c "from __future__ import nested_scopes" is not supported. What's the point? To support these changes, many function variants have been added to pythonrun.c. All the variants names end with Flags and they take an extra PyCompilerFlags * argument. It is possible that this complexity will be eliminated in a future version of the interpreter in which nested scopes are not optional.
2001-03-22 10:47:58 +08:00
DL_IMPORT(int) PyRun_SimpleFileExFlags(FILE *, char *, int, PyCompilerFlags *);
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) PyRun_InteractiveOne(FILE *, char *);
Useful future statement support for the interactive interpreter (Also remove warning about module-level global decl, because we can't distinguish from code passed to exec.) Define PyCompilerFlags type contains a single element, cf_nested_scopes, that is true if a nested scopes future statement has been entered at the interactive prompt. New API functions: PyNode_CompileFlags() PyRun_InteractiveOneFlags() -- same as their non Flags counterparts except that the take an optional PyCompilerFlags pointer compile.c: In jcompile() use PyCompilerFlags argument. If cf_nested_scopes is true, compile code with nested scopes. If it is false, but the code has a valid future nested scopes statement, set it to true. pythonrun.c: Create a new PyCompilerFlags object in PyRun_InteractiveLoop() and thread it through to PyRun_InteractiveOneFlags().
2001-03-02 06:59:14 +08:00
DL_IMPORT(int) PyRun_InteractiveOneFlags(FILE *, char *, PyCompilerFlags *);
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) PyRun_InteractiveLoop(FILE *, char *);
Extend support for from __future__ import nested_scopes If a module has a future statement enabling nested scopes, they are also enable for the exec statement and the functions compile() and execfile() if they occur in the module. If Python is run with the -i option, which enters interactive mode after executing a script, and the script it runs enables nested scopes, they are also enabled in interactive mode. XXX The use of -i with -c "from __future__ import nested_scopes" is not supported. What's the point? To support these changes, many function variants have been added to pythonrun.c. All the variants names end with Flags and they take an extra PyCompilerFlags * argument. It is possible that this complexity will be eliminated in a future version of the interpreter in which nested scopes are not optional.
2001-03-22 10:47:58 +08:00
DL_IMPORT(int) PyRun_InteractiveLoopFlags(FILE *, char *, PyCompilerFlags *);
"Compiling" version
1990-12-20 23:06:42 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(struct _node *) PyParser_SimpleParseString(char *, int);
DL_IMPORT(struct _node *) PyParser_SimpleParseFile(FILE *, char *, int);
Ugly. A pile of new xxxFlags() functions, to communicate to the parser that 'yield' is a keyword. This doesn't help test_generators at all! I don't know why not. These things do work now (and didn't before this patch): 1. "from __future__ import generators" now works in a native shell. 2. Similarly "python -i xxx.py" now has generators enabled in the shell if xxx.py had them enabled. 3. This program (which was my doctest proxy) works fine: from __future__ import generators source = """\ def f(): yield 1 """ exec compile(source, "", "single") in globals() print type(f())
2001-07-16 13:37:24 +08:00
DL_IMPORT(struct _node *) PyParser_SimpleParseStringFlags(char *, int, int);
DL_IMPORT(struct _node *) PyParser_SimpleParseFileFlags(FILE *, char *,
int, int);
"Compiling" version
1990-12-20 23:06:42 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(PyObject *) PyRun_String(char *, int, PyObject *, PyObject *);
DL_IMPORT(PyObject *) PyRun_File(FILE *, char *, int, PyObject *, PyObject *);
Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), PyRun_FileEx(). These are the same as their non-Ex counterparts but have an extra argument, a flag telling them to close the file when done. Then this is used by Py_Main() and execfile() to close the file after it is parsed but before it is executed. Adding APIs seems strange given the feature freeze but it's the only way I see to close the bug report without incompatible changes. [ Bug #110616 ] source file stays open after parsing is done (PR#209)
2000-08-28 03:21:52 +08:00
DL_IMPORT(PyObject *) PyRun_FileEx(FILE *, char *, int,
PyObject *, PyObject *, int);
Extend support for from __future__ import nested_scopes If a module has a future statement enabling nested scopes, they are also enable for the exec statement and the functions compile() and execfile() if they occur in the module. If Python is run with the -i option, which enters interactive mode after executing a script, and the script it runs enables nested scopes, they are also enabled in interactive mode. XXX The use of -i with -c "from __future__ import nested_scopes" is not supported. What's the point? To support these changes, many function variants have been added to pythonrun.c. All the variants names end with Flags and they take an extra PyCompilerFlags * argument. It is possible that this complexity will be eliminated in a future version of the interpreter in which nested scopes are not optional.
2001-03-22 10:47:58 +08:00
DL_IMPORT(PyObject *) PyRun_StringFlags(char *, int, PyObject *, PyObject *,
PyCompilerFlags *);
DL_IMPORT(PyObject *) PyRun_FileFlags(FILE *, char *, int, PyObject *,
PyObject *, PyCompilerFlags *);
DL_IMPORT(PyObject *) PyRun_FileExFlags(FILE *, char *, int, PyObject *,
PyObject *, int, PyCompilerFlags *);
"Compiling" version
1990-12-20 23:06:42 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(PyObject *) Py_CompileString(char *, char *, int);
Extend support for from __future__ import nested_scopes If a module has a future statement enabling nested scopes, they are also enable for the exec statement and the functions compile() and execfile() if they occur in the module. If Python is run with the -i option, which enters interactive mode after executing a script, and the script it runs enables nested scopes, they are also enabled in interactive mode. XXX The use of -i with -c "from __future__ import nested_scopes" is not supported. What's the point? To support these changes, many function variants have been added to pythonrun.c. All the variants names end with Flags and they take an extra PyCompilerFlags * argument. It is possible that this complexity will be eliminated in a future version of the interpreter in which nested scopes are not optional.
2001-03-22 10:47:58 +08:00
DL_IMPORT(PyObject *) Py_CompileStringFlags(char *, char *, int,
PyCompilerFlags *);
Move a bunch of definitions that were internal to compile.c to symtable.h, so that they can be used by external module. Improve error handling in symtable_enter_scope(), which return an error code that went unchecked by most callers. XXX The error handling in symtable code is sloppy in general. Modify symtable to record the line number that begins each scope. This can help to identify which code block is being referred to when multiple blocks are bound to the same name. Add st_scopes dict that is used to preserve scope info when PyNode_CompileSymtable() is called. Otherwise, this information is tossed as soon as it is no longer needed. Add Py_SymtableString() to pythonrun; analogous to Py_CompileString().
2001-02-03 02:19:15 +08:00
DL_IMPORT(struct symtable *) Py_SymtableString(char *, char *, int);
* Fixed some subtleties with fastlocals. You can no longer access f_fastlocals in a traceback object (this is a core dump hazard if there are <nil> entries), but instead eval_code() merges the fast locals back into the locals dictionary if it looks like the local variables will be retained. Also, the merge routines save exceptions since this is sometimes needed (alas!). * Added id() to bltinmodule.c, which returns an object's address (identity). Useful to walk arbitrary data structures containing cycles. * Added compile() to bltinmodule.c and compile_string() to pythonrun.[ch]: support to exec/eval arbitrary code objects. The code that defaults globals and locals is moved from run_node in pythonrun.c (which is now identical to eval_node) to eval_code in ceval.c. [XXX For elegance a clean-up session is necessary.]
1993-03-31 01:46:03 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) PyErr_Print(void);
DL_IMPORT(void) PyErr_PrintEx(int);
Add sys.excepthook. Update docstring and library reference section on 'sys' module. New API PyErr_Display, just for displaying errors, called by excepthook. Uncaught exceptions now call sys.excepthook; if that fails, we fall back to calling PyErr_Display directly. Also comes with sys.__excepthook__ and sys.__displayhook__.
2001-03-23 10:46:52 +08:00
DL_IMPORT(void) PyErr_Display(PyObject *, PyObject *, PyObject *);
"Compiling" version
1990-12-20 23:06:42 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) Py_AtExit(void (*func)(void));
pythgonrun.h: added Py_AtExit(). rename1.h: add PyArg_GetInt.
1994-09-07 22:35:10 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) Py_Exit(int);
* Added support for X11 modules. * Makefile: change location of FORMS library. * posixmodule.c: turn #if 0 into #ifdef MSDOS (stuff in unistd.h or not) * Almost all .h files: added CPP magic to avoid duplicate inclusions and to support inclusion from C++.
1993-07-28 17:05:47 +08:00
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(int) Py_FdIsInteractive(FILE *, char *);
Added decl for Py_FdIsInteractive.
1997-02-15 03:51:34 +08:00
Added declarations for Py_{Set,Get}ProgramName() and a bunch of other Py_Get*() functions.
1997-07-20 03:50:52 +08:00
/* In getpath.c */
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(char *) Py_GetProgramFullPath(void);
DL_IMPORT(char *) Py_GetPrefix(void);
DL_IMPORT(char *) Py_GetExecPrefix(void);
DL_IMPORT(char *) Py_GetPath(void);
Added declarations for Py_{Set,Get}ProgramName() and a bunch of other Py_Get*() functions.
1997-07-20 03:50:52 +08:00
/* In their own files */
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(const char *) Py_GetVersion(void);
DL_IMPORT(const char *) Py_GetPlatform(void);
DL_IMPORT(const char *) Py_GetCopyright(void);
DL_IMPORT(const char *) Py_GetCompiler(void);
DL_IMPORT(const char *) Py_GetBuildInfo(void);
Added declarations for Py_{Set,Get}ProgramName() and a bunch of other Py_Get*() functions.
1997-07-20 03:50:52 +08:00
Mass checkin (more to follow for other directories). Introduce truly separate (sub)interpreter objects. For now, these must be used by separate threads, created from C. See Demo/pysvr for an example of how to use this. This also rationalizes Python's initialization and finalization behavior: Py_Initialize() -- initialize the whole interpreter Py_Finalize() -- finalize the whole interpreter tstate = Py_NewInterpreter() -- create a new (sub)interpreter Py_EndInterpreter(tstate) -- delete a new (sub)interpreter There are also new interfaces relating to threads and the interpreter lock, which can be used to create new threads, and sometimes have to be used to manipulate the interpreter lock when creating or deleting sub-interpreters. These are only defined when WITH_THREAD is defined: PyEval_AcquireLock() -- acquire the interpreter lock PyEval_ReleaseLock() -- release the interpreter lock PyEval_AcquireThread(tstate) -- acquire the lock and make the thread current PyEval_ReleaseThread(tstate) -- release the lock and make NULL current Other administrative changes: - The header file bltinmodule.h is deleted. - The init functions for Import, Sys and Builtin are now internal and declared in pythonrun.h. - Py_Setup() and Py_Cleanup() are no longer declared. - The interpreter state and thread state structures are now linked together in a chain (the chain of interpreters is a static variable in pythonrun.c). - Some members of the interpreter and thread structures have new, shorter, more consistent, names. - Added declarations for _PyImport_{Find,Fixup}Extension() to import.h.
1997-08-02 10:56:48 +08:00
/* Internal -- various one-time initializations */
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(PyObject *) _PyBuiltin_Init(void);
DL_IMPORT(PyObject *) _PySys_Init(void);
DL_IMPORT(void) _PyImport_Init(void);
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
DL_IMPORT(void) _PyExc_Init(void);
Mass checkin (more to follow for other directories). Introduce truly separate (sub)interpreter objects. For now, these must be used by separate threads, created from C. See Demo/pysvr for an example of how to use this. This also rationalizes Python's initialization and finalization behavior: Py_Initialize() -- initialize the whole interpreter Py_Finalize() -- finalize the whole interpreter tstate = Py_NewInterpreter() -- create a new (sub)interpreter Py_EndInterpreter(tstate) -- delete a new (sub)interpreter There are also new interfaces relating to threads and the interpreter lock, which can be used to create new threads, and sometimes have to be used to manipulate the interpreter lock when creating or deleting sub-interpreters. These are only defined when WITH_THREAD is defined: PyEval_AcquireLock() -- acquire the interpreter lock PyEval_ReleaseLock() -- release the interpreter lock PyEval_AcquireThread(tstate) -- acquire the lock and make the thread current PyEval_ReleaseThread(tstate) -- release the lock and make NULL current Other administrative changes: - The header file bltinmodule.h is deleted. - The init functions for Import, Sys and Builtin are now internal and declared in pythonrun.h. - Py_Setup() and Py_Cleanup() are no longer declared. - The interpreter state and thread state structures are now linked together in a chain (the chain of interpreters is a static variable in pythonrun.c). - Some members of the interpreter and thread structures have new, shorter, more consistent, names. - Added declarations for _PyImport_{Find,Fixup}Extension() to import.h.
1997-08-02 10:56:48 +08:00
Added prototype for various finalizers.
1997-08-12 22:57:21 +08:00
/* Various internal finalizers */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
DL_IMPORT(void) _PyExc_Fini(void);
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(void) _PyImport_Fini(void);
DL_IMPORT(void) PyMethod_Fini(void);
DL_IMPORT(void) PyFrame_Fini(void);
DL_IMPORT(void) PyCFunction_Fini(void);
DL_IMPORT(void) PyTuple_Fini(void);
DL_IMPORT(void) PyString_Fini(void);
DL_IMPORT(void) PyInt_Fini(void);
DL_IMPORT(void) PyFloat_Fini(void);
DL_IMPORT(void) PyOS_FiniInterrupts(void);
Added prototype for various finalizers.
1997-08-12 22:57:21 +08:00
Added decls for stuff from myreadline.
1997-08-12 23:14:22 +08:00
/* Stuff with no proper home (yet) */
ANSI-fication and Py_PROTO extermination.
2000-07-09 08:55:06 +08:00
DL_IMPORT(char *) PyOS_Readline(char *);
extern DL_IMPORT(int) (*PyOS_InputHook)(void);
extern DL_IMPORT(char) *(*PyOS_ReadlineFunctionPointer)(char *);
implements PyOS_CheckStack for Windows and MSVC. this fixes a couple of potential stack overflows, including bug #110615. closes patch #101238
2000-08-28 03:15:31 +08:00
/* Stack size, in "pointers" (so we get extra safety margins
on 64-bit platforms). On a 32-bit platform, this translates
to a 8k margin. */
#define PYOS_STACK_MARGIN 2048
Use suggested workaround for PyOS_CheckStack causing failure of test_[s]re.py on Win64. This closes bug http://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=116516
2000-10-12 01:18:11 +08:00
#if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
implements PyOS_CheckStack for Windows and MSVC. this fixes a couple of potential stack overflows, including bug #110615. closes patch #101238
2000-08-28 03:15:31 +08:00
/* Enable stack checking under Microsoft C */
#define USE_STACKCHECK
#endif
Added a prototype for PyOS_CheckStack (within #ifdef USE_STACKCHECK).
2000-08-08 05:00:42 +08:00
#ifdef USE_STACKCHECK
implements PyOS_CheckStack for Windows and MSVC. this fixes a couple of potential stack overflows, including bug #110615. closes patch #101238
2000-08-28 03:15:31 +08:00
/* Check that we aren't overflowing our stack */
DL_IMPORT(int) PyOS_CheckStack(void);
Added a prototype for PyOS_CheckStack (within #ifdef USE_STACKCHECK).
2000-08-08 05:00:42 +08:00
#endif
Added decls for stuff from myreadline.
1997-08-12 23:14:22 +08:00
Add typedef PyOS_sighandler_t and prototypes for PyOS_getsig() and PyOS_setsig().
2000-09-17 00:31:31 +08:00
/* Signals */
typedef void (*PyOS_sighandler_t)(int);
DL_IMPORT(PyOS_sighandler_t) PyOS_getsig(int);
DL_IMPORT(PyOS_sighandler_t) PyOS_setsig(int, PyOS_sighandler_t);
* Added support for X11 modules. * Makefile: change location of FORMS library. * posixmodule.c: turn #if 0 into #ifdef MSDOS (stuff in unistd.h or not) * Almost all .h files: added CPP magic to avoid duplicate inclusions and to support inclusion from C++.
1993-07-28 17:05:47 +08:00
#ifdef __cplusplus
}
#endif
#endif /* !Py_PYTHONRUN_H */
Reference in New Issue Copy Permalink