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

91–97 of 97 posts

Re: C puzzles

#91

Post by i336_ »

gowrikumar wrote: post #77

OP here! Started getting a lot of mails seeking answers for the puzzles. Was wondering what triggered all this and learnt about this post.

This is excellent chewing material, hence the upvotes.

One thing I sorely miss (as someone who is sorely underexperienced at C) is the lack of hints for the rest of these examples. I'm reading them and trying to keep up with what they do.

(I must admit, I am one of probably many who (lazily!) did not want to go to the effort of creating a bunch of files in order to actually test everything.)

Re: C puzzles

#92

Post by metaphor »

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

> A 2 space indent... A 4 space indent... I have been wondering for a while now why is it that everybody is stuck with this typewriter/punchcard mentality and assumes that only a fixed-width (non-proportional) font could be used to display program code on a computer screen. Would it not be more appropriate, in this century, to realize that since indentation (and spacing in general) is essentially something that only…

>> Would it not be more appropriate, in this century, to realize that since indentation (and spacing in general) is essentially something that only pertains to the graphical representation of program's code...

False assumption.

Suppose a language exists which: 1.) truncates all characters beyond the 80th prior to interpretation; 2.) will throw an exception during run-time if tab characters are used for indentation; 3.) strictly defines, in BNF, valid cases for the first 7 column-wise characters, of which 7 spaces is distinctly meaningful.

Although it may be "this century", I think I speak for more than a few who continue to maintain the corrected mistakes of our predecessors out of economic necessity...and I'm not talking about reaping a paycheck either.

Re: C puzzles

#93

Post by bogomipz »

gowrikumar wrote: post #84
bogomipz wrote: post #63

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?

Some of the questions have a pointers to the reading material. I will try to get the answers updated this week.

That would be great! I will look forward to seeing these.

Re: C puzzles

#94

Post by userbinator »

Orangeair wrote: post #74

I have a problem with these puzzles that it seems like no one has pointed out. A couple of them are just intentionally misleading, specifically the ones that involve typos. For example, the solution to one of them is that it says 'defa1ut' instead of 'default' in a case statement. Ignoring the question of whether or not typos are really "puzzles", this is misleading because the syntax highlighting the author uses hig…

I think that's the whole idea behind these being puzzles --- someone who uses syntax highlighting as a sort of crutch will stumble over these, while those who are actually looking at the characters won't. One of the other ones does something similar with a comment, and it made me giggle a little as I caught it immediately. It's somewhat similar to a https://en.wikipedia.org/wiki/Stroop_effect experiment.

I bet even more would be confused if the 'defa1ut' one said 'defau1t' --- showing how font choice can also be very important to readability.

Re: C puzzles

#95

Post by mnay »

hatsunearu wrote: post #13

That IA-64 one is really puzzling, anyone know what the heck is happening?

The code in question violates the newer C standards (C99, C11). For instance, it doesn't even compile using "gcc -std=c99 -pedantic-errors".

In the older C standard (C89), the code has undefined behaviour because implicit declaration of the function malloc is not compatible with its definition in the standard library. It is a futile task to try to define the undefined.

Re: C puzzles

#97

Post by mikeash »

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

Yup! that's correct. Later versions of compilers have become intelligent with standard library function and I doubt if this reproes on the current compilers - for standard library functions.

It definitely doesn't happen in whatever recent versions of clang and gcc I tested with. I had to wrap malloc in a function that the compiler didn't have a special case for in order to make reproduce the crash.
Post reply on HN