[Python-Dev] RE: More informative error messages
Scott David Daniels
Scott.Daniels at Acm.Org
Wed Oct 8 11:26:43 EDT 2003
More information about the Python-Dev mailing list
Wed Oct 8 11:26:43 EDT 2003
- Previous message: [Python-Dev] Re: [spambayes-dev] spambayes-checkins -> spambayes-dev, python-checkins -> python-dev
- Next message: [Python-Dev] RE: More informative error messages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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
- Previous message: [Python-Dev] Re: [spambayes-dev] spambayes-checkins -> spambayes-dev, python-checkins -> python-dev
- Next message: [Python-Dev] RE: More informative error messages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list