Some dark corners of C • Hacker News Board

Re: Some dark corners of C

#31

Post by matthiasv » Sat, Mar 09, 2013, 1:18 PM UTC

Sharlin wrote: post #28

gjulianm wrote: 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.

The pre-processor is independent and a macro expanded before the C compiler sees it.

Re: Some dark corners of C

#32

Post by enqk » Sat, Mar 09, 2013, 1:22 PM UTC

gjulianm wrote: post #18

tobiasu wrote: post #5

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

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

#33

Post by rjek » Sat, Mar 09, 2013, 1:32 PM UTC

tobiasu wrote: post #20

rjek wrote: post #7

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

Good, because I was missing a slide: = Bitfields = Not even once. ;)

Everybody knows about bitfields :)

Re: Some dark corners of C

#34

Post by lttlrck » Sat, Mar 09, 2013, 1:33 PM UTC

grn wrote: post #29

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

That's stdlib though, not the language.

Re: Some dark corners of C

#35

Post by PommeDeTerre » Sat, Mar 09, 2013, 1:35 PM UTC

dualogy wrote: post #4

copx wrote: post #2

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

It's obviously JavaScript and PHP that are being referred to.

Of the C "dark corners" that are problematic, it'd be extremely rare to run into them in most real-world code. You'd have to intentionally go out of your way to write code that will trigger them, and this code often looks obviously suspicious.

It's very much the opposite with JavaScript and PHP. A world of pain and danger opens up the moment you do something as simple as an equality comparison. The problems that can and will arise are well documented, so I won't repeat them here, but it's a much worse (and unavoidable) situation than when compared to C, C++, Java, C#, Python, Ruby or other mainstream languages.

Re: Some dark corners of C

#36

Post by lttlrck » Sat, Mar 09, 2013, 1:36 PM UTC

dakimov wrote: post #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.

Is banging your head against the wall violating the semantics of life?

Re: Some dark corners of C

#37

Post by eliben » Sat, Mar 09, 2013, 1:47 PM UTC

Most of these "dark corners" have been in C for at least 25 years and have been repeated over an over for at least 20.

My main take-away from this is that Google Drive seems like a nice way to put presentations online :-)

Re: Some dark corners of C

#38

Post by tobinfricke » Sat, Mar 09, 2013, 1:49 PM UTC

rwmj wrote: post #9

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!

Re: Some dark corners of C

#39

Post by cliffbean » Sat, Mar 09, 2013, 1:52 PM UTC

tobiasu wrote: post #5

gjulianm wrote: 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…

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…

> If your code lacks the declaration of the function, the compiler will assume pre ANSI-C semantics and generate code returning an int.

Better, please help by compiling your C code with -Wimplicit-function-declaration (included in -Wall), and fixing all the problems it reports. Then you won't have to worry about this problem, or a bunch of other problems.

Re: Some dark corners of C

#40

Post by gngeal » Sat, Mar 09, 2013, 2:05 PM UTC

tobinfricke wrote: post #8

dualogy wrote: post #4

Earlier quoted context omitted.

> which shall not be named So... not that telling then.

The most egregious example in common usage: PHP. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Hah, a nice article. :-) My favourite sentence from the PHP documentation:

string create_function ( string $args , string $code )

"Creates an anonymous function from the parameters passed, and returns a unique name for it."

So there you are. Of course you can choose to be an anonymous value, but you'll get a name assigned by the state, for free. :-) Fascinating logic, captain.