How to install Python package from source on Windows

[Chris Angelico]

On Fri, May 19, 2017 at 10:40 AM, Michael Torrie <torriem at 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