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

111–120 of 175 posts

Re: Some dark corners of C

#111

Post by kstenerud »

robotresearcher wrote: post #102
kstenerud wrote: post #64

Earlier quoted context omitted.

The question assumes that you KNOW the rule, which is highly unlikely unless you've either been bitten by it or have read through the spec enough times to catch it. Unless you know the actual parsing rules, there's no way to know if a real parser would be greedy or not (or perhaps it might try to be clever?). This is nothing more than a trivia question, which does not test aptitude or intelligence.

It does test knowledge. Nothing wrong with knowledge. I expect they asked some other questions too.

It tests esoteric (aka borderline useless) knowledge. There's a big difference between that and, say, knowing how to use something actually useful like double pointers.

I had no idea how the C parsing algorithm worked for +++ et al, and I'm an expert C programmer. Then again, I'd also never use such ridiculous constructs in production code.

Re: Some dark corners of C

#112

Post by tsahyt »

popee wrote: post #61
tsahyt wrote: post #52

Earlier quoted context omitted.

At least or exactly 10 elements?

At least

Huh, I didn't know that. I just checked the standard and you appear to be correct, so, just for the record:

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

#113

Post by udp »

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…

> While we're talking about dark corners, please stop casting functions that return void *

The problem is, if I want my C code to compile with MSVC, it has to compile as C++ - and even if I abhor Windows for development myself, a lot of developers are using MSVC.

I just wish Microsoft would update their C compiler, at least to C90. But then I suppose the standard has only been around for 23 years, and nobody really uses C anyway.

Re: Some dark corners of C

#115

Post by geon »

gngeal wrote: post #83
geon wrote: post #48

Earlier quoted context omitted.

In this case it isn't so weird, since PHP pre 5.3 didn't have first class functions. To pass a function around, you would use a variable containing a string of it's name. create_function was a way to A) not having to define a function separately B) not getting problems with the function being re-defined, since each call would create a new function C) fake closures by generating code. All this should be moot points by…

That's true (except for C), because I can't see how a create_function-defined function closes over its environment), but what I had in mind was the way in which the author of the documentation, obviously one of the PHP core developers, talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is. But I suppose that goes naturally hand in hand with the…

> That's true (except for C), because I can't see how a create_function-defined function closes over its environment),

That's why it would be a fake closure.

    $foo = someNumber();
    create_function('', 'return '.$foo.';');
You would generate a new string to be evaluated as the function body each time.

> talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is.

I think you read too much into this. The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code.

It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable.

    $foo = 42;
    $bar = 'foo';
    print($$bar); // Prints 42.

Re: Some dark corners of C

#116

Post by temac »

dilap wrote: post #59
enqk wrote: post #32

Earlier quoted context omitted.

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.

An annoying thing C++. Anyone know the history/rationale of this change?

It is supposed to provide you more checking by disabling automatic cast from void* to any other pointer. This makes sense in C++ since casting a pointer to a class can trigger some address adjustement if the target class of this instance pointed to is multiple derived (and maybe in other cases?). There is no way such adjustment can happen if the source type is void*, because then you don't know what the source type really is.

Re: Some dark corners of C

#117

Post by JoshTriplett »

rjek wrote: post #33
tobiasu wrote: post #20

Earlier quoted context omitted.

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

Everybody knows about bitfields :)

Bitfields have some crazy fun dark corners, though. For instance, which values can this bitfield hold:

    int b:1;
Signed two's-complement n-bit integers can hold values from 2^(n-1)-1 to -2^(n-1), so in theory it can hold 0 and -1, but many compilers get that one wrong. Always declare one-bit bitfields as unsigned. (The Sparse static analyzer will warn you about that one.)

Re: Some dark corners of C

#118

Post by temac »

graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

Don't think the K&R book is the standard. The standard now exists and is detailed enough, for what C aims at being. As for doing maths in C or wanting managed allocation, it is well there are better languages for that (and it was even better wide know twenty years ago for the math part...)

You seems to have found some that works well for your needs so everything is good.

Re: Some dark corners of C

#120

Post by scott_s »

graycat wrote: post #79

For "dark corners of C", when I was writing C code I had several serious concerns. Below I list eight such in roughly descending order on 'seriousness': First, what are malloc() and free() doing? That is, what are the details, all the details and exactly how they work? It was easy enough to read K&R, see how malloc() and free() were supposed to be used, and to use them, but even if they worked perfectly I was unsure…

If you ever program in C again, use valgrind to help debug your programs: http://valgrind.org/

It's particularly useful for bugs related to memory.

Post reply on HN