[Scott David Daniels] > setjmp/longjmp are nightmares for compiler writers. I was one for 15 years, so that won't scare me off <wink>. > The writers tend to turn off optimizations around them and/or get > corner cases wrong. > ... They do. I would aim for a tiny total number of setjmp and longjmp calls, inside very simple functions. So, e.g., a routine that wanted to die with an error wouldn't call longjmp directly, it would call a common utility function containing the longjmp. The latter function simply wouldn't return. Optimizations short of interprocedural analysis aren't harmed then in the calling function, because nothing in *that* is the target, or direct source, of a non-local goto. Last I looked, the Perl source seemed to do such a thing in places, and that's about as widely ported as Python. It struck me with force when I was looking at Perl's version of an adaptive mergesort last year, and got jealous of how much shorter and clearer the C code could be when every stinkin' call didn't have to be followed by an error test-and-branch. The Python sort code hides most of that syntactically via macros, but the runtime cost is always there. In real life, not one sort in a million actually raises an exception, so executing O(N log N) test-branch blocks per sort has astronomically low bang for the buck. In cases like that (which are common), it doesn't matter how slow actually raising an exception would be; it's not even tempting to put the longjmp calls inline. Whatever, I'll never have time to pursue it, so screw it <wink>.
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