>> ./pypcre.c:4524: warning: variable `start_bits' might be >> clobbered by `longjmp' or `vfork' >> ./pypcre.c:4525: warning: variable `start_match' might be >> clobbered by `longjmp' or `vfork' [Tim sez these are almost always bogus wngs, Martin sez these two are legit] The start_bits wng is bogus because start_bit's only definition points precede the do-loop: start_bits will either be NULL or extra->start_bits by the time the "do" is entered, and can never change after that (yes, start_bits "appears" in the loop, but not as an lvalue -- it's only referenced). So the value setjmp tucks away is necessarily the correct value for longjmp to restore. This is a purely local flow question; knowledge of when a longjmp may occur isn't needed. I agree the start_match wng is legit. In my previous life, I tracked down about a hundred of these, and found only one that was legit. So pypcre is as sick as Dragon's half-million lines of speech recognition code <wink>. "The usual" way to fix this is to slop "volatile" onto the declarations, as the author already did for three other locals. That's the second reason this warning sucks: it depends on which locals gcc decides to carry in registers, and that varies from release to release. And that's the third reason this warning sucks: gcc is actually complaining about its *own* decision to carry something in a register <0.1 wink -- and if it *knows* it's not safe to carry something in a register, it shouldn't!>.
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