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

C puzzles

gowrikumar.com

Post reply on HN
Print view View original

61–70 of 97 posts

Re: C puzzles

#61

Post by btilly »

mkagenius wrote: post #48
btilly wrote: post #32

Earlier quoted context omitted.

Really, are we going to argue about the One True Formatting style? A 2 space indent is more compact. A 4 space indent is more readable for older people. Putting braces around blocks on their own lines highlights blocks. Putting braces inline is again more compact. Outdenting declarations highlights an important piece of information. Keeping them in line focuses on blocks. And so on. None of these choices are particul…

> Be consistent with code around you I sometimes forget what i did in last function, so in my code there might be inconsistencies and a mix of both styles found. I hope to get consistent some day but a working code is the priority right now :)

In a code base there ideally should be a single coding standard. Achieving this ideal always seems impossible. But various languages have various tools to enable mass reformatting to fix this if there is no current consistency. This turns the problem from being a technical one to a social one.

Good luck with reaching agreement with your fellow developers...

Re: C puzzles

#62

Post by amptorn »

When I make a programming language, one of its core design principles will be that there should be no puzzles like this.

Re: C puzzles

#63

Post by bogomipz »

These are interesting. Does anyone know if the explanations are provided anywhere? Or at least what the insight into the why of some of these?

Re: C puzzles

#64

Post by asamy45 »

abbeyj wrote: post #56
asamy45 wrote: post #33

Earlier quoted context omitted.

No. The int to int * truncation does not happen, the cast does not matter. What matters is the `int *p' which is 64-bit on 64-bit systems, so the compiler will just move the returned value in RAX into wherever p is, so no truncation happens, even without the cast. Look at the generated assembly, you'll see what I mean.

The question asks about IA-64 (Itanium) and IA-32. You're talking about the RAX register which is x86-64. If you call malloc without a prototype in scope, bad things can happen. Just because it happens to work out OK with the platform and compiler that you tested doesn't mean that it will work everywhere or that it will keep working in the future.

His scope of talk sounds as if he is referring to x86-64. Many people mistake the IA-64 for x86-64, that's why I assumed he'd be talking about it. Not to mention that IA-32 refers to x86, which he clearly seems to misunderstand.

Re: C puzzles

#65

Post by asamy45 »

mikeash wrote: post #50
asamy45 wrote: post #49

Earlier quoted context omitted.

Doesn't happen for me. Both GCC and Clang compile it fine.

Strange. Here's my erroring code: int main() { int* p; p = (int*)wrapped_malloc(sizeof(int)); *p = 10; return 0; } void *wrapped_malloc(int size) { return malloc(size); } And the actual error: test.c:9:11: error: conflicting types for 'wrapped_malloc' void *wrapped_malloc(int size) { ^ test.c:4:19: note: previous implicit declaration is here p = (int*)wrapped_malloc(sizeof(int)); Are you doing anything differently?

No, I am not sure why this happens.

Re: C puzzles

#66

Post by UhUhUhUh »

CapacitorSet wrote: post #3

I really dislike his choice of coding style. Compare: int CountBits (unsigned int x ) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF } ; int i ; int shift ; /* Number of positions to shift to right*/ for ( i =0, shift =1; i > shift) & mask[i]); return x; } as opposed to: int countBits (unsigned int x) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x0…

I agree, formatting is like punctuation in a narrative. Not massively significant but certainly not meaningless. There is a sort of rhythm, flavor, style, whatever you want to call it, that winds up being part of it all. And it can prevent mistakes.

Re: C puzzles

#67

Post by asamy45 »

innocenat wrote: post #44
mikeash wrote: post #14

Earlier quoted context omitted.

There's no #include first, so you get an implicit prototype for malloc. With an implicit prototype, the function is assumed to return int. The cast then converts the returned int to int*. This works on 32-bit where int is the size of a pointer, but on 64-bit with 32-bit ints, the top half of the pointer gets chopped off and you end up with a nonsense value. This is why it's considered bad form to cast the result of m…

Oh so he meant to say Intel 64/amd64. IA-64 is Intel Itanium. I just skipped it because I know nothing about IA-64 at all.

Actually he clearly misunderstands the difference, IA-32 refers to x86, which he then says IA-64, which refers to Itanium, which is sort of a bad comparison then.

Re: C puzzles

#68

Post by asamy45 »

mikeash wrote: post #60
mfukar wrote: post #55

Earlier quoted context omitted.

Close. Sign extension. But this is a C puzzle, so I'd get away with "undefined behaviour".

Where does sign extension occur here?

The movslq instruction will sign extend the upper 32 bits.

Re: C puzzles

#69

Post by mikeash »

asamy45 wrote: post #68
mikeash wrote: post #60

Earlier quoted context omitted.

Where does sign extension occur here?

The movslq instruction will sign extend the upper 32 bits.

Right you are! Thanks. I tried to check, but didn't realize my test case had produced a zero bit in that position so didn't expose sign extension.

Re: C puzzles

#70

Post by CapacitorSet »

btilly wrote: post #32
CapacitorSet wrote: post #3

I really dislike his choice of coding style. Compare: int CountBits (unsigned int x ) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF } ; int i ; int shift ; /* Number of positions to shift to right*/ for ( i =0, shift =1; i > shift) & mask[i]); return x; } as opposed to: int countBits (unsigned int x) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x0…

Really, are we going to argue about the One True Formatting style? A 2 space indent is more compact. A 4 space indent is more readable for older people. Putting braces around blocks on their own lines highlights blocks. Putting braces inline is again more compact. Outdenting declarations highlights an important piece of information. Keeping them in line focuses on blocks. And so on. None of these choices are particul…

>None of these choices are particularly important. Being CONSISTENT does.

The thing is - there isn't much consistency in his syntax. The most obvious example is the indentation, that appears to be 8 spaces except for one line which is indented with 4; there isn't consistency in whether to have a space or not before semicolons, before and after parentheses, or before and after binary operators.

Post reply on HN