On Fri, May 19, 2017 at 10:40 AM, Michael Torrie <torr...@gmail.com> wrote: >> Since you are ultimately compiling the code in C, those ideas of undefined >> behaviour etc do apply. The behaviour of the C compiler doesn't suddenly, >> magically, change just because the code was generated by a program in >> another language. If <some code> generates warnings because it relies on >> undefined behaviour, it is still undefined behaviour regardless of whether >> you typed the code yourself or used a code generator. > > Of course not, and I don't think that was Bart's point at all. He was > just pointing out that some of the compiler warnings folks jumped all > over in his code stem from the compiler warning that the operator > precedence in certain expressions is often not what the programmer > wants. But since Bart is aware of the precedence (and that's part of > the C standard so there's no undefined behavior there), his generated C > expressions can lack parenthesis since they are already are in the > correct order of operations. You can argue that this isn't the case if > you want, but I see no reason to doubt Bart's word in this thing. Sure > he could place parens in the expression to quiet the warning (might be > the best bet), but that is redundant and this is clearly a case of a > warning that can be ignored.
There were multiple warnings emitted. Some were about parentheses; personally, I would have the codegen emit them, simply because it makes everything clearer. (A lot of machine-generated code has superfluous parentheses, simply because it's easier than coding to omit them.) Those weren't the warnings that were mentioned with reference to undefined behaviour, because the C standard is very clear about operator precedence, and the warnings are only there because it's sometimes confusing to mix "and" and "or" conditions. But "variable may be used uninitialized"? That's a much more serious warning. I don't know what gcc defines as "may" here, and whether the generated code actually has no path that could lead to the variable actually being referenced prior to being given a value; but certainly this is not one to casually dismiss. Before trusting this code, I would want to see a more thorough audit (maybe with a tool like Coverity) to prove that it actually won't be reading junk memory. The one that Steve saw even without enabling all warnings (regarding the signedness of an overly-large integer constant) may or may not itself be a problem, but at very least, it's indicative of some assumptions regarding word size and exactly how long a "long long" is. It's possible that the code will work flawlessly if "long long" is 64-bit, but will fail if it's 128-bit. Or maybe it'll succeed on a 128-bit CPU but only with certain compilation settings. Or maybe it's actually all fine, and gcc just misunderstood something. How would we know? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
