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

Massacring C Pointers

wozniak.ca

Post reply on HN
Print view View original

271–280 of 300 posts

Re: Massacring C Pointers

#271

Post by berti »

bitL wrote: post #172
mannykannot wrote: post #169

Earlier quoted context omitted.

In the 90's there was at least one good software book: 'The C Programming Language' by messrs. Kernighan and Ritchie - you may have heard of it? It correctly told you, among other things, everything you really need to know about using pointers in C. It is still available.

I was a kid back then; K&R was pretty hard to find in my area and it was quite outdated anyway, most people were happy to use whatever resources they could get; the best in mid-to-late 90s ended up things like what DJ Delorie wrote, stuff from John Carmack, Dave Eberly etc. that were pretty low on rigor but very high on practical value.

K&R is still not outdated!

Re: Massacring C Pointers

#272

Post by azernik »

gumby wrote: post #82
azernik wrote: post #80

Bad reviews are always so much more fun to read than good ones.

To review your comment: "The author's well meaning and accurate comment is that well-written negative reviews are typically far more fun to read than positive ones of any quality -- in the positive case you usually want to simply read the book, while the implication of the comment is that the pleasure of reading the negative ones is a delicious Schadenfreude . "Regrettably, this insight was obscured by a regrettable…

Short trumps correct.

Re: Massacring C Pointers

#273

Post by daemin »

0xffff2 wrote: post #245
Improvotter wrote: post #220

Earlier quoted context omitted.

Some of my professors also have ridiculous code standards or exam standards. One of them teaches "algorithms and data structures", but he's not allowing us to even use a break or continue in our loops because he thinks it's "bad practice". We end up with a nested hellhole. Another example from the same professor (correct me if I'm wrong on this as I'm not a C++ expert), but he's constantly inheriting from unique or s…

>Another example from the same professor (correct me if I'm wrong on this as I'm not a C++ expert), but he's constantly inheriting from unique or shared pointers in his classes. Like why though? You are not wrong. This completely breaks my brain. I really would love to hear the professor's explanation for this.

The same thing as people inheriting from standard containers. It does not make sense!

It's like people see inheritance and then forget that containment is a thing.

Re: Massacring C Pointers

#274

Post by daemin »

phaedrus wrote: post #219
setquk wrote: post #70

This doesn't surprise me really. When I was at university the programming textbooks we had were vile nasty and plainly incorrect. And those of us who dared challenge it by writing correct, robust code were penalised as the staff teaching it didn't understand the domain of what they were teaching properly and didn't have any real experience and assumed we were doing it wrong. We learned quickly to approach education w…

Along the lines of taking the authority of a book as a replacement for critical thinking... I was once hired to rewrite some assembly language spaghetti code a more-electronic-than-software engineer had worked on for two years. Ostensibly he was ordered to help me accomplish this, but he was more like what in court would be described as a "hostile witness" I spent a couple of months "hacking", just familiarizing myse…

That seriously sounds like someone that has only learnt through rote memorisation. Absolutely great at taking tests and doing things by the book but completely unable to apply the things they should have learned to a problem that falls slightly outside the examples.

Great story though, even though it makes me shudder.

Re: Massacring C Pointers

#275

Post by daemin »

saulrh wrote: post #9
the_lurker wrote: post #4

Yesterday I encountered a similar program on a HN comment chain as shown in this link. I am genuinely confused as to why this program is bad. I am a student and I do not know the best practices regarding pointers, but it is how I would write a program to combine two strings. Can someone please elaborate why it is bad? Are their any good resources to fill gaps in my knowledge? Thanks in advance. Edit: Thank you guys f…

Not a C programmer, so I'm sure I'm missing a ton of more subtle issues, but some of the immediate questions to ask: * What happens if s or t are longer than 100 characters? * What happens if s and t are both longer than 50 characters? * What happens if no element of s == '\0'? How about t? * r is allocated on the stack. What happens to the memory pointed at by r when you call another function after calling combine?…

For the first two points, you end up overwriting the stack and most likely crash. This is how security holes were/are made.

For the third point, you have two main ways of storing strings in general. The first was called pascal style, where the length is stored first in either a byte or two and then the string data with no (or an optional) terminating null character (the '\0'). The second is referred to as c style, and is done by storing the string in a memory and denoting the end of the buffer by a null character.

The c-style enables certain nicer looking c code with loops and such, but it is more dangerous and potentially expensive if you recompute the length all the time. You can always mix and match the way you store the string, such as in C++ where the string class stores a length as well as a null terminated string in a buffer.

For your forth point, yes, you end up corrupting the string leading to more crashes and/or it can be used as an entry point to screw around with your program's stack.

Re: Massacring C Pointers

#276

Post by mannykannot »

bitL wrote: post #212
mannykannot wrote: post #193

Earlier quoted context omitted.

> Where do you see me defending that book? We could begin from your post starting this thread, where your implication that its errors are just optimizations suggests that you did not understand what's actually, indisputably wrong with the code from the book. Your comment here about current knowledge strongly suggests that you still do not. There are several posts here that explain exactly why it was simply wrong the…

Frankly, it's really difficult to talk to people that always run syntactic analyzers on everything written and aren't open to absorb the full context. Do I need to go step by step to talk what was wrong with the code? You are mistaking generosity (i.e. it has faults, but it was in a different age) with stupidity (I have no clue what I am talking about; despite writing my own compilers, writing self-modifying code in…

I think there is at least one thing we can agree on, which is that the author of this book sincerely wanted to help people.

Re: Massacring C Pointers

#277

Post by [deleted] »

burfog wrote: post #257
nwmcsween wrote: post #39

Earlier quoted context omitted.

The issue with really learning computer science outside top well known schools is that you're basically on your own for education (or worse if taught wrong). Open source software somewhat teaches you things but usually by trial by fire.

That isn't totally wrong, but I think you drew the line in the wrong place. There are numerous less-known schools that are OK, but a typical community college or liberal arts school isn't going to deliver the goods. State universities are sometimes good.

[deleted]

Re: Massacring C Pointers

#278

Post by 08-15 »

Improvotter wrote: post #220
phaedrus wrote: post #211

When I started my CS degree the school was transitioning from teaching C++ to teaching Java, and the state of instruction in C++ was almost as bad as these examples. I had a professor who wanted us to use "new Foo()" everywhere in our code (even local / static variables) because it, "gets the students ready for Java." No matching delete, of course, or mention of RAII. We were supposed to "pretend" we had a garbage co…

Some of my professors also have ridiculous code standards or exam standards. One of them teaches "algorithms and data structures", but he's not allowing us to even use a break or continue in our loops because he thinks it's "bad practice". We end up with a nested hellhole. Another example from the same professor (correct me if I'm wrong on this as I'm not a C++ expert), but he's constantly inheriting from unique or s…

> he's constantly inheriting from unique or shared pointers in his classes

That happens when you learn OOP from a bad teacher or text book. Far too many books focused entirely on class hierarchies, as if an inheritance diagram was an almost completed program. That leads to a weird kind of brain damage where you think all problem can and must be solved by inheriting from something. It was the STL that taught people that algorithms matter more than taxonomies, but clearly some professors never got the memo.

Re: Massacring C Pointers

#279

Post by beojan »

Wrongthink wrote: post #163
beojan wrote: post #153

Earlier quoted context omitted.

And that's why just going to the cheapest university is a bad idea.

My mid tier university has a fundamental problem where the lecturers aren't even hired to teach, they're hired for research. And since the university can't get enough American grad students to stay and be research slaves they bring in grad students from the third world. Then these grad students are required by law to teach a certain number of credit hours to conduct research and there you go. The result is every gene…

The professors or graduate students hired to do research aren't the ones who end up teaching wildly incorrect material. That happens when you hire people specifically to teach, and don't pay them very much at all.

Re: Massacring C Pointers

#280

Post by [deleted] »

huhtenberg wrote: post #79
jmts wrote: post #27

Earlier quoted context omitted.

Most of these points are covered by the other comments. As a C programmer professionally, I'll go into a little more depth, and offer an alternative implementation for comparison. The function in question: char *combine(s, t) char *s, *t; { int x, y; char r[100]; strcpy(r, s); y = strlen(r); for (x = y; *t != '\0'; ++x) r[x] = *t++; r[x] = '\0'; return(r); } 1. The array 'r' is allocated on the stack, and returned fr…

if (NULL == s) Ouch. I haven't seen a single case where this abomination actually helped catching the fearsome 'if (s = NULL)' typo. One needs to be a sloppy typist, not paying attention to what they write, not proof-reading the code before committing and ignoring compiler warnings for this disaster of a notation to be even remotely justified.

[deleted]
Post reply on HN