On Fri, May 19, 2017 at 5:29 AM, bartc <b...@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 -- https://mail.python.org/mailman/listinfo/python-list
