A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/038592.html below:

[Python-Dev] RE: More informative error messages

[Python-Dev] RE: More informative error messagesScott David Daniels Scott.Daniels at Acm.Org
Wed Oct 8 11:26:43 EDT 2003
[Tim Peters]

>....  OTOH, almost
>every call to a C API function has to test+branch for an error-return value,
>and I've often wondered whether a setjmp/longjmp-based hack might allow for
>cleaner and more optimizable code (hand-rolled "real exception handling").
>
setjmp/longjmp are nightmares for compiler writers.   The writers tend 
to turn
off optimizations around them and/or get corner cases wrong.  If you 
read the
C standard, precious little is guaranteed around setjmp/longjmp.  The C 
code
using disciplined setjmp/longjmp, will read well, probably be be quite
optimizable, but ....

At least some of the C compilers will mis-optimize such code and others 
will be
painfully slow due to the interaction of two compiler coding strategies: 
first,
emit straightforward sloppy code easily cleaned up in the optimization 
passes,
and second, turn off optimization in the presence of setjmp/longjmp.

Maybe the general compiler world has changed, but I had nightmares 
supporting
a language which generated C including setjmp/longjmp calls, and ran it on
top of three C compilers.  Each compiler had nasty cases to avoid, and the
resulting least common denominator was painfully inept.

-Scott David Daniels


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4