Noted by Joseph Armbruster; patch by Jessica McKellar.
The original code was 'for (;;) {...}', where ... ended
with a 'return -2' statement and did not contain a 'break' or 'continue'
statement. Therefore, the body of the loop is always executed once.
Once upon a time there was a 'continue' in the loop, but it was removed in
rev36346, committed by mwh on Wed Jul 7 17:44:12 2004.
mismatches. At least I hope this fixes them all.
This reverts part of my change from yesterday that converted everything
in Parser/*.c to use PyObject_* API. The encoding doesn't really need
to use PyMem_*, however, it uses new_string() which must return PyMem_*
for handling the result of PyOS_Readline() which returns PyMem_* memory.
If there were 2 versions of new_string() one that returned PyMem_*
for tokens and one that return PyObject_* for encodings that could
also fix this problem. I'm not sure which version would be clearer.
This seems to fix both Guido's and Phillip's problems, so it's good enough
for now. After this change, it would be good to review Parser/*.c
for consistent use of the 2 memory APIs.
malloc/realloc type functions, as well as renaming one variable called 'new'
in tokensizer.c. Still lots more to be done, going to be checking in one
chunk at a time or the patch will be massively huge. Still compiles ok with
gcc.
This was the result of inconsistent use of PyMem_* and PyObject_* allocators.
By changing to use PyObject_* allocator almost everywhere, this removes
the inconsistency.
because (essentially) I didn't realise that PY_BEGIN/END_ALLOW_THREADS
actually expanded to nothing under a no-threads build, so if you somehow
NULLed out the threadstate (e.g. by calling PyThread_SaveThread) it would
stay NULLed when you return to Python. Argh!
Backport candidate.
[ 960406 ] unblock signals in threads
although the changes do not correspond exactly to any patch attached to
that report.
Non-main threads no longer have all signals masked.
A different interface to readline is used.
The handling of signals inside calls to PyOS_Readline is now rather
different.
These changes are all a bit scary! Review and cross-platform testing
much appreciated.
This gets us closer to consistent Ctrl+C behaviour on NT and Win9x. NT now reliably generates KeyboardInterrupt exceptions for NT when a file IO operation was aborted. Bugfix candidate
Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.
This closes SourceForge patch #101659 and bug #115323.
Work around intrcheck.c's desire to pass 'PyErr_CheckSignals' to
'Py_AddPendingCall' by providing a (static) wrapper function that has the
right number of arguments.
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
Also grandly renamed.
Here's the new interface:
When WITH_READLINE is defined, two functions are defined:
- PyOS_GnuReadline (what used to be my_readline() with WITH_READLINE)
- PyOS_ReadlineInit (for Dave Ascher)
Always, these functions are defined:
- PyOS_StdioReadline (what used to be my_readline() without WITH_READLINE)
- PyOS_Readline (the interface used by tokenizer.c and [raw_]input().
There's a global function pointer PyOS_ReadlineFunctionPointer,
initialized to NULL. When PyOS_Readline finds this to be NULL, it
sets it to either PyOS_GnuReadline or PyOS_StdioReadline depending on
which one makes more sense (i.e. it uses GNU only if it is defined
*and* stdin is indeed a tty device).
An embedding program that has its own wishes can set the function
pointer to a function of its own design. It should take a char*
prompt argument (which may be NULL) and return a string *ending in a
\n character* -- or "" for EOF or NULL for a user interrupt.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Andrew M. Kuchling
Neal Norwitz
Anthony Baxter
Michael W. Hudson
Tim Peters
Jack Jansen
Martin v. Löwis
Mark Hammond
Guido van Rossum
Fred Drake
Thomas Wouters