I remember when the Pentium F00F bug was reported, I tested it by doing: char main[] = { 0xf0, 0x0f, 0xc7, 0xc8, 0xc3 }; (and yes, my machine -- a Pentium MMX -- hung solid and I was rather shocked!)
whoah - I find that construction astonishing. My gcc compiles it with only this warning: foo.c:2:6: warning: ‘main’ is usually a function [-Wmain] hah!
Some dark corners of C
51–60 of 175 posts
Re: Some dark corners of C
#52#define struct union #define else That's evil. I have to do it in someone's code some day just to have some fun. But, apart from that, it's a really nice compilation. I didn't know about the compile time checks of array sizes, but I have a doubt. What if I pass to a method declared int foo(int x[static 10]) this pointer int* x = (int*) calloc(20, sizeof(int)); Does the compiler skip the check? Does it give me a warni…
The purpose of int foo(int x[static 10]) is not to produce a warning - that's just a nice possible side-effect (and only in some cases). The real purpose is to allow the compiler to optimise the compilation of the foo() function itself, under the assumption that x will always point to the first element of an array of at least 10 elements.
Re: Some dark corners of C
#53I don't get it. What will happen if you violate the language semantics? They call it 'dark corners'? If you hit your head against a wall, it will hurt. Is it a 'dark corner' of life? Overall, the presentation is very weak, like from a yesterday's graduate.
I've got quite a bit of experience with C, and I haven't heard of the "static" array size feature before, which seems extremely useful.
Re: Some dark corners of C
#54Earlier quoted context omitted.
That sounds like a university to avoid.
It's necessarily a bad question, it makes you think about how parsers work. But for an entrance exam, it's slightly hardcore :)
Re: Some dark corners of C
#55Just like everything else programming languages have evolved. From Assembly to Fortran to C to Java/C# (just saying, no exact sequence implied). I dont think the languages we have now, far from perfection they may be, would have been possible without the "dark corners" in the older languages. We learnt from them and made better languages. So I say show respect to the old languages, learn from them and keep improving…
We haven't all learned... https://www.destroyallsoftware.com/talks/wat :P
Re: Some dark corners of C
#56#define struct union #define else That's evil. I have to do it in someone's code some day just to have some fun. But, apart from that, it's a really nice compilation. I didn't know about the compile time checks of array sizes, but I have a doubt. What if I pass to a method declared int foo(int x[static 10]) this pointer int* x = (int*) calloc(20, sizeof(int)); Does the compiler skip the check? Does it give me a warni…
The purpose of int foo(int x[static 10]) is not to produce a warning - that's just a nice possible side-effect (and only in some cases). The real purpose is to allow the compiler to optimise the compilation of the foo() function itself, under the assumption that x will always point to the first element of an array of at least 10 elements.
Re: Some dark corners of C
#57I remember when the Pentium F00F bug was reported, I tested it by doing: char main[] = { 0xf0, 0x0f, 0xc7, 0xc8, 0xc3 }; (and yes, my machine -- a Pentium MMX -- hung solid and I was rather shocked!)
whoah - I find that construction astonishing. My gcc compiles it with only this warning: foo.c:2:6: warning: ‘main’ is usually a function [-Wmain] hah!
Re: Some dark corners of C
#58Nevermind, it would take more than the Lord of the Rings triology.
Re: Some dark corners of C
#59Earlier quoted context omitted.
In my university they always told me to cast the return of void * functions, I thought it was just to avoid the warning saying "automatic cast of void* to int*" or similar. Thanks, I will take that into account.
It is true in C++, not in C where void* needs no casting. People tended to confuse C++ with C more in the past, as they had not diverged as much as they have now.
Re: Some dark corners of C
#60#define struct union #define else That's evil. I have to do it in someone's code some day just to have some fun. But, apart from that, it's a really nice compilation. I didn't know about the compile time checks of array sizes, but I have a doubt. What if I pass to a method declared int foo(int x[static 10]) this pointer int* x = (int*) calloc(20, sizeof(int)); Does the compiler skip the check? Does it give me a warni…
Last time this came up on HN, it was thought to be a clang feature. Edit: While we're talking about dark corners, please stop casting functions that return void * . If your code lacks the declaration of the function, the compiler will assume pre ANSI-C semantics and generate code returning an int . On machines where pointers do not fit ints (basically all 64bit machines), you just silently (due to the cast there is n…
typedef void ( * fptr_t)()
and cast to fptr_t instead of void * But it's bigger problem how to force users to cast it back to proper prototype, because casting it back to something else will give UB.