That's fun. Cause I remember this "x+++y;" as a question in one of my university entrance exams!
Some dark corners of C
11–20 of 175 posts
Re: Some dark corners of C
#12It is telling that these "dark corners" all seem harmless compared to what you can find in certain other languages which shall not be named.
> which shall not be named So... not that telling then.
I think we all know what language (s)he meant.
But about those dark corners, I guess the point wasn't to present any particularly nasty gotchas, but rather some precious little lesser known tricks. C has plenty of very well known features you can be bitten by (mostly related to memory management, of course). While the presentation reiterates over some of them, the most valuable parts are about various _good_ parts of the language which are rarely heard of (viz. the usage of `static` inside brackets).
Re: Some dark corners of C
#13Very cool.
I remember hearing that the disallowal of pointer aliasing was the main reason that it was possible for a Fortran compiler to produce code that could outperform code from a C compiler: It allows the compiler to perform a new class of optimizations.
It would appear that the restrict keyword lets C programs regain that class of compiler optimizations.
Re: Some dark corners of C
#14Earlier quoted context omitted.
It's a C99 feature, and clang's the only compiler I know of that produces the diagnostic (and only in later versions) btw; I wrote this talk.
I didn't know that. To answer my previous question, clang doesn't fire a warning when passing pointers of any size to the function foo. And by the way, nice talk, it's great learning these dark secrets of C.
But a pointer is not the same thing as an array, a pointer does not carry the size of the allocated space which an array does in the same scope.
Re: Some dark corners of C
#15Earlier quoted context omitted.
It's a C99 feature, and clang's the only compiler I know of that produces the diagnostic (and only in later versions) btw; I wrote this talk.
I didn't know that. To answer my previous question, clang doesn't fire a warning when passing pointers of any size to the function foo. And by the way, nice talk, it's great learning these dark secrets of C.
The compiler can't know at compile time with a naked pointer like it can with an array. [static 1] is handy to say it must not explicitly be NULL, as if it were optional, however.
Re: Some dark corners of C
#16That's fun. Cause I remember this "x+++y;" as a question in one of my university entrance exams!
That sounds like a university to avoid.
Re: Some dark corners of C
#17#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…
It's impossible to have a static decision procedure about dynamic properties of programs, such as the size of dynamically allocated memory areas (Rice's theorem). So, it is necessary to either include false positives (correct programs rejected) or false negatives (incorrect programs accepted).
Sound static analyzers fall in the first case, but require a lot of work to become precise enough to be used (ie, to reduce the number of false alarms). Compilers fall in the second case in the sense that they don't have to honor such a clause. And in the C99 norm it's actually a "shall" (it just couldn't honor a "must" in that case):
"If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression."
Re: Some dark corners of C
#18#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…
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.
Re: Some dark corners of C
#19Earlier quoted context omitted.
I didn't know that. To answer my previous question, clang doesn't fire a warning when passing pointers of any size to the function foo. And by the way, nice talk, it's great learning these dark secrets of C.
The compiler can't know at compile time with a naked pointer like it can with an array. [static 1] is handy to say it must not explicitly be NULL, as if it were optional, however.
Yes, but I expected some kind of "You're passing a pointer as an array of size n. I can't check the size, but you should make sure you've checked it".
Re: Some dark corners of C
#20Earlier quoted context omitted.
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…
It's a C99 feature, and clang's the only compiler I know of that produces the diagnostic (and only in later versions) btw; I wrote this talk.
Good, because I was missing a slide:
= Bitfields =
Not even once.
;)