How to install Python package from source on Windows

[Chris Angelico]

On Fri, May 19, 2017 at 5:29 AM, bartc <bc at freeuk.com> wrote:
> On 18/05/2017 19:50, Chris Angelico wrote:
>
>> Now this, however, is more serious. Those warnings scare me, too. (I
>> just tried it.) Instead of being "gcc is noisy", these are "your code
>> is sloppy". These are exactly why I tell most people NOT to write in
>> C. For machine-generated code, this is IMO unacceptable. Maybe
>> "-Wno-unused" is okay (machine-generated code often has some junk in
>> it), but all the uninitialized variables? No way. Doesn't matter what
>> compiler you use, run it in all-warnings-enabled mode at least once as
>> part of testing your codegen.
>
>
> The rules are different when you are writing in a different language and
> only use a C compiler to compile the intermediate code.

Only if your codegen is magically perfect. What happens if you have a
bug in your compiler? What if it emits incorrect C code?

> Before it becomes C, the code has already been largely verified. C might
> still pick up some things, if the first compiler doesn't check them.

"largely" verified. Can you be absolutely certain that not one of
these compiler-detected issues is actually a problem? Would you stake
your life on it - for example, would you compile this code and put it
in charge of an airliner that you then ride on?

> But C is dominated by its ideas of what is undefined behaviour and what is
> implementation defined, which don't match the model used in the original
> language. That language might only be designed for a small set of
> architectures where everything is well defined, whereas C is expected to run
> on every conceivable architecture ever devised.
>
> So the original language can decide that converting a 64-bit pointer (to
> 'void') to a 64-bit function pointer is fine, provided there is a cast. But
> C might not like it because on some obscure machine, function pointers work
> differently. You need to do a lot of work to shut up the compiler (and it
> still won't work on that obscure machine).

In other words, you are *DELIBERATELY* making your program
non-portable. Why not just distribute a binary instead? You're not
gaining any portability.

> Bear in mind C allows you to do this:
>
> int *A[10];    // array of pointers to int
> int (*B)[10];  // pointer to array of int
> int i;
>
> *A[i];         // index then deref to get the int
> (*B)[i];       // deref then index to get the int
>
> That's fine so far: one is an array of pointers, other is a pointer to an
> array. However, you can also do this:
>
> (*A)[i];       // deref an array then index
> *B[i];         // index a pointer then deref
>
> which is wrong, and can crash the program. A compiler however will not
> detect it as it is perfectly legal, meanwhile it will deluge you with
> hundreds of pointless warnings.
>
> In my original language, such a mixup is illegal. So, do you still trust a C
> compiler more? The language is inherently unsafe.

I know that there are problems with C. But you don't eliminate them by
saying "I compile other code via C". Even with complete unit-test
coverage, you can't prove that your translator is 100% bug-free. And
how much test coverage *do* you have, bartc?

ChrisA