[falcolas]

Some absolutely fascinating points. However, I must admit that the portion on link pointers was, frankly, damned frightening as someone who could possibly have to come back and figure out what's really going on.

I'm reminded of Perl when I look at that link pointer code. It's succinct, easy to write, works great most of the time, and nearly impossible to go back and decode later. You simply require too much context to find the one place where you stepped beyond the array and into no-man's land.

I love pointers; I think that like other sharp tools, they have their uses. However, like other sharp tools, they require training and attention to use properly. Lots of people lose fingers to saws every year; how many brain cells have you lost to debugging pointer mistakes?

[tptacek]

That's idiomatic C code. You're right that it's not particularly readable if you aren't a C programmer, but if you came to a job interview and couldn't grok it immediately, I'd write "facility with C: marginal" in my notes.

[falcolas]

Missed this back closer to when you posted it - but it's less that I don't understand what's going on, and more that this code is more likely to go wrong & be harder to debug than more descriptive code.

Just the other day, I was trying to identify what was being done by someone's "idiomatic" code, and had to keep three vertical screen's worth of data up just to follow what was happening. All that code was wrong, but because they were using pointers "idiomatically", it took a long time to find their off-by-one error.

Granted, they had gone about 4 levels further with pointers than the given example in the article, but the premise is similar.