[MAL] > ceval.c: In function `eval_code2': > ceval.c:345: warning: `v' might be used uninitialized in this function > ceval.c:346: warning: `w' might be used uninitialized in this function > ceval.c:347: warning: `u' might be used uninitialized in this function > ceval.c:348: warning: `t' might be used uninitialized in this function [Fred] > These would be a real tedium to fix, and I'm not convinced the loss > of clarity is worth it. I'll take this one. It looks easy to fix, and to my eye doing *everything* needed for oparg == 5 in a single block (ditto for 4, 3, 2, 1 in their own blocks) would be much clearer than the current distributed trickiness (faster, too -- the code now is branching more than computing). > From looking at the code in the DUP_TOPX code, I'm led to think that > the compiler just isn't smart enough (it should figure out that oparg > won't change before the second case statement, and figure it out more > carefully. I'll bet *that* would remove these warnings and still right > in all cases. I agree, except that it wasn't trivial for *me* to decide the compiler was being stupid. Code that's obviously correct is better than code that's not obviously wrong. >> errors.c: In function `PyErr_Format': >> errors.c:409: warning: value computed is not used >> errors.c:415: warning: value computed is not used Thanks! > Fixed. Thanks!
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