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

211–220 of 300 posts

Re: Massacring C Pointers

#211

Post by phaedrus »

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 collector. By that logic one might prepare students for a course in Spanish by speaking English with a "-o" on the end of every word.

On one of the early homework assignments I realized my professor misunderstood how pointers work - he seemed to believe that (re)assigning pointers created chains rather than changing what the pointer points at. I.e. given "int x,y; int_pointer a,b,c; a=b=c=&x;" he seemed to believe that then executing "c=&y;" would also cause "a" and "b" to point at "y".

I spent the first page of my turned-in assignment excoriating his lack of understanding. Then I presented a class template that implemented a special smart pointer which did behave in the unusual way he seemed to think C pointers work, so that I could write the code exactly as he presented in the assignment and make it actually work.

In retrospect I could have been nicer and considered other pedagogical factors beside technical correctness. I think he took it with more grace than I deserved.

Re: Massacring C Pointers

#212

Post by bitL »

mannykannot wrote: post #193
bitL wrote: post #185

Earlier quoted context omitted.

Where do you see me defending that book? I haven't ever read it. I am making fun of looking back 3 decades and judging it with our current knowledge. What you can do in 10s for $0.001 now took often half a year and millions of $ to accomplish back then, if ever. It's just ridiculous to get offended by some book that didn't get it perfectly right and was likely used by smart readers as an exercise of recognizing incor…

> 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 assembly language, using super duper optimizations in C++ that crashed compilers because nobody expected them etc.). Thank you very much and good luck with your literal approach!

Actually, reading that code was fun for me. I wish I could go so low level these days in the mainstream...

Re: Massacring C Pointers

#213

Post by tho09823ntaoent »

narag wrote: post #69
stinos wrote: post #60

Earlier quoted context omitted.

He was a former BASIC book author too Hmm, I'm starting to see a pattern. Is it possible BASIC, plus lack of internet back in the day, plus attrocious books are the reasons for truning poeple into terrible programmers? I happen to know only a couple of seniors but without exception their code, no matter what language written in today, is horrible on all fronts. I used to think it was a lack of attention to detail, th…

I did learn BASIC first, but then Pascal and in college and from books very soon learned the foundations of structured programming. It was an instant aha! since as soon as you write anything but trivial programs, you feel you need functions. What I find disturbing is that author thought every language was the same save a few keywords, and then publisher was happy to put that crap to print.

Yeah, the quote about a professional C programmer rejecting it and the publisher publishing it anyway was telling!

Re: Massacring C Pointers

#214

Post by [deleted] »

maxlybbert wrote: post #205
bitL wrote: post #98

Earlier quoted context omitted.

I'll bite: argument from authority can be reversed - if Brian didn't mess up the language design, these sorts of "code drivels" wouldn't have appeared! I think you've heard that argument from many language designers already... Then we can argue that back in those times it was something progressive etc. And we are straight back with the argument I was making. When you read StackOverflow, books on Deep Learning or comp…

Kernighan didn’t actually design C. He wrote a book with Dennis Ritchie, who did.

[deleted]

Re: Massacring C Pointers

#216

Post by _kst_ »

simias wrote: post #63
int0x80 wrote: post #24

Earlier quoted context omitted.

It is wrong in many ways. It copies s and then t to a fixed size buffer, without any checks. That will write to invalid memory (probably smashing the stack) if len(s), len(t) or len(s) + len(t) > 100. It returns a stack allocated buffer (r) pointer to the caller. The array will be invalid when the function returns, as the automatic variables only live in the function scope (during the call), they are deallocated when…

You're right, although any mention of strncpy should come with a big disclaimer that it's effectively broken because you can end up with a non-NULL terminated string in some cases. strlcpy should be the way to go but unfortunately it's not part of the C standard and not available everywhere (sometimes for rather bullshit reason IMO, but that's a different story).

NULL is (a macro that expands to) a null pointer constant. The null character '\0' is commonly called NUL.

I've written about strncpy: http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

Re: Massacring C Pointers

#217

Post by macintux »

huhtenberg wrote: post #108
jmts wrote: post #102

Earlier quoted context omitted.

And thus in your disgust you have actually given a case where this convention might actually save somebody time. If it happens to end up being your own time, you ought to be thankful for it. You certainly don't want it to be wasting your customer's time. I actually recently saw an 'if (x = 0)' or similar get caught in review recently. Time pressure increases, tests are rushed, and authors proof-read the code in their…

For all intents and purposes this is one of many typo classes that just happens to have a cute "antidote", and which also has been all but rendered pointless by the existence of respective compiler warnings. I've seen weirder stuff get through the reviews and compile cleanly, something like "f,()". Typos happen, but (a) it's not a good enough reason to make the code less readable (b) if the code is prone to this sort…

I strongly disagree that this impacts code readability, except perhaps for a beginner, but stretching a beginner’s mind a bit with a concept that’s not exactly a major challenge to understand hardly seems like a crime against humanity.

Re: Massacring C Pointers

#218

Post by ehaliewicz2 »

jschwartzi wrote: post #187
simias wrote: post #115

Earlier quoted context omitted.

I'm not saying it's hard to work around but I maintain it's broken. You have a function that deals with C-string that in some conditions returns something that's not a C-string but can't be trivially distinguished from one and will trigger undefined behavior if used like one. It's terrible ergonomics and almost certainly not what you want to do in any situation. You can argue that truncation is an error condition but…

I can use a sledgehammer to break my leg, but that doesn't mean the hammer is broken by design. I just have to be careful where I swing the hammer and what I hit with it.

That's a poor analogy. It calls itself a string function but isn't. So it's more like a airsoft gun that actually shoots bullets, but you don't know until you decide to shoot yourself in the leg to see what it feels like.

Re: Massacring C Pointers

#219

Post by phaedrus »

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 myself with the microcontroller and its instruction set, and the tooling. (In fact, I had no source code to look at during this time, as he would not surrender it!) When I finally got his source, I rewrote it to a 100% functional equivalent in two weeks, 1/5 the size without all the unnecessary control path duplication and without pointless register moves. At the time I found the way he had used register moves particularly puzzling because it resembled the way an un-optimized compiler might work.

Months later after I was no longer on that project, I got a call from him. He was very flustered and wanted to know where I "got" a particular sequence of instructions from. I was like, come again? He said, "It's not in the book. You used a sequence of instructions that's not in the Book." (The Microchip programming manual.) He asked about another block of 3 or 4 instructions - also not in the book (in the combination I used them in).

Slowly it dawned on me - I'm quite certain he didn't understand what any individual instruction "did". That whole level level of abstraction didn't exist for him. He programmed in assembly, yes, but only using blocks of example instructions from the Book. Suddenly the pointless register moves made sense - he was acting as a human compiler, without an optimization step.

Years later I realized I should have asked him, "and how do you think the example code in the book was written?"

Re: Massacring C Pointers

#220

Post by Improvotter »

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 shared pointers in his classes. Like why though? Why do you have to complicate your code like this? Why can't you just have a normal class with unique or shared pointers in it?

Lastly, and this is taught by another professor, is my class for Linux. It includes bash and C++ programming and focuses a bit on the POSIX API. Our exam was last week and we had 3 parts. The first part was a theory exam by the professor that taught the class. It was about bash/POSIX commands and very little Linux specific stuff. He expected us to know all of the options from all of the commands you can think of: cut, split... You had to know all of them and off the top of your head. It's ridiculous. I'm pretty sure I failed that one, but I absolutely nailed the next part which was about bash scripting (where you could use if statements and the like, the first part did not allow it, only redirection and piping). The man is mad (hah man, that's what I needed during that first exam part).

Post reply on HN