Live data from Hacker News

Some dark corners of C

docs.google.com

21–30 of 175 posts

Re: Some dark corners of C

#21
post #13

Very 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.

It's pretty well explained here

http://en.wikipedia.org/wiki/Restrict

Re: Some dark corners of C

#23
A very interesting read!

By the way, shouldn't the right hand side text on slide 7 (the final part of slide 7) talk about the pointers z and x, instead of the values pointed at? (Aside: How do I write "asterisk x" on HN without getting an italicized x?)

Re: Some dark corners of C

#24
post #3

#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…

About evil preprocessor construct, there is a nice collection in the comment of this Jonh Regehr post : http://blog.regehr.org/archives/574

Re: Some dark corners of C

#26
post #3

#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…

Could someone explain to us newbies what the #define code does?...

Re: Some dark corners of C

#27
I 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.

Re: Some dark corners of C

#28
post #3

#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…

Isn't re-#defining language keywords disallowed by the C standard? It's just that most compilers don't complain about it.

Re: Some dark corners of C

#29
It's also worth pointing out that buffers passed to strcpy, memcpy, etc. must not overlap. Otherwise it results in undefined behavior.

Re: Some dark corners of C

#30
post #26
post #3

#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…

Could someone explain to us newbies what the #define code does?...

It replaces the first word with what comes after. For example, #define foo bar is roughly equivalent to s/foo/bar/g, so #define else would just remove all else keywords. I'll let you guess what it does to a program.
Post reply on HN