Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some dark corners of C

docs.google.com

Post reply on HN
Print view View original

1–10 of 175 posts

Re: Some dark corners of C

#2

Post by copx »

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.

Re: Some dark corners of C

#3

Post by gjulianm » 

    #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 warning?

EDIT: Funnily enough, in Mac it doesn't give any warning, neither for pointers nor for undersized arrays (ie, foo(w[5]) doesn't give a warning). And I've compiled with -std=c99 -pedantic -Wall.

Re: Some dark corners of C

#5

Post by tobiasu »

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 no warning) truncated a pointer. Worse, it may work depending on the malloc implementation and how much memory you allocate.

We have to fix these kinds of bugs on OpenBSD a lot, please help by typing less and let the compiler warn you about silly mistakes :-)

And yes, C++ fucked this up for C. I'll leave it to Linus to say something nice about that..

Re: Some dark corners of C

#6

Post by [deleted] »

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…

[deleted]

Re: Some dark corners of C

#7

Post by rjek »

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…

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.

Re: Some dark corners of C

#8

Post by tobinfricke »

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.

The most egregious example in common usage: PHP.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Re: Some dark corners of C

#9

Post by rwmj »

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!)

Re: Some dark corners of C

#10

Post by gjulianm »

rjek wrote: post #7
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…

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.

Post reply on HN