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

61–70 of 300 posts

Re: Massacring C Pointers

#61

Post by wernsey »

de_watcher wrote: post #10

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - Dijkstra, "How do we tell truths that might hurt?" (1975) The author, Traister, has came from BASIC. We have the explanation.

I also thought of that quote while reading the article, yet I disagree with Dijkstra.

I think an appropriately skilled developer would be able to write a useful application in BASIC in the same way that the same programmer would be able to write something useful in assembler.

I wouldn't want to write a large program in a language like that though, but I do think in the 80s programmers had to make do with what they had

Re: Massacring C Pointers

#62

Post by grive »

bboreham wrote: post #46
leodeid wrote: post #17

Earlier quoted context omitted.

I haven't touched C in years, but here's my descending "wtf" list: 1. Returns pointer to stack-allocated data, which immediately becomes invalid. Instead, it should be using some sort of allocation (e.g. 'malloc'), or taking in a destination pointer. 2. 'r' is arbitrarily set with length 100. Smaller strings don't need all that space, and larger strings definitely will overrun. 3. The function signature is really awk…

> 'strcpy' should usually be replaced by 'strncpy' Sorry to butt in, but this is a bit of a trigger for me: I’ve had to fix a number of programs infected with this idea. The main problems with strncpy are: When the source string is shorter than n, strncpy will pad the target to n bytes, filling with zeros. This is bad for performance. When the source string is longer than n, strncpy will copy n bytes but _not_ nul-te…

> Sadly there is no standard replacement that is widely accepted.

True, but practically: when having access to BSD extensions, strl* are used. If only C standard is available, snprintf is preferred. I have seen C libs that will check for strl* availability, and if not, reimplement them using snprintf.

So for portability, snprintf is the way to go. For correctness, and pushing for their extended use, strl* is nice.

Re: Massacring C Pointers

#63

Post by simias »

int0x80 wrote: post #24
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…

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).

Re: Massacring C Pointers

#64

Post by okyougotmenow »

stinos wrote: post #60
narag wrote: post #51

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too. I can't warn you bec…

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…

Most of the major game engines of the past 20-30 years were programmed in a large part by people that started with BASIC.

Re: Massacring C Pointers

#65

Post by scatters »

saagarjha wrote: post #29
konstmonst wrote: post #21

Earlier quoted context omitted.

There are multiple problems with that code: 1) return(r) He is returning pointer to temporary! When you declare and initialize variables on stack after that function, they will overwrite memory pointed by r. 2) He is assuming size of string pointed by s(including 0) is less than 100 and also the combined sizes of s and t are less than 100. Stack Overflow! 3) Not an errors, but would not pass my code review: Inconsist…

> Inconsistent Variable declaration How so? > I would have used strcpy 2 times You can't do this, because strcpy doesn't give you the length of the string you copied, which is necessary to put the trailing null byte.

strcpy writes a trailing zero.

> The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest.

Re: Massacring C Pointers

#66

Post by _7c18 »

martin1975 wrote: post #55

Apparently Mr Traister has written a number of other books - https://www.amazon.com/default/e/B001H6UPHY/ - according to Amazon... Made me wonder if the quality of the content in the other 11 books is anything like the one the Woz took apart.

It's not Steve Wozniak. They just happen to share the same last name. From https://wozniak.ca:

> I’m Geoff Wozniak, just one of those persons on the Internet. My blog is hosted here, but not much else at the moment.

Re: Massacring C Pointers

#67

Post by oldcynic »

stinos wrote: post #60
narag wrote: post #51

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too. I can't warn you bec…

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 would say "it depends".

Just as poor programmers came later from Visual Basic, or MSVC++ (somehow we went through a phase were everyone coming for interview with MSVC++ actually had C with classes, and for a while it was a warning sign and standing joke at the place I then worked). Getting people who claimed C++ who actually knew it was pretty challenging around the millennium.

In the 80s just about everyone who had an 8 bit started with BASIC, and an awful lot of them managed to go on to be perfectly acceptable programmers when they moved on to C, C++, assembler, and more recent languages, or even turned out a decent game in something like Blitz Basic on the Amiga. Then again there were some who couldn't move beyond BASIC, because it was simple enough almost everyone could piece something together with it - so even back then it was a warning like PHP can be today.

It's not age, and it's not BASIC - there's plenty of younger folks turning out abysmal code who've never been near it.

I wonder how I'd have turned out if I'd learnt C from one of this guy's books instead of K&R and having a couple of experts handy.

Re: Massacring C Pointers

#68

Post by oblio »

waffle_ss wrote: post #58

I was going to ask if any attempt was made to reach the book author for comment, but it looks like he died in 2007. RIP. https://www.findagrave.com/memorial/29007415/robert-joseph-t...

Damn, that's sad. I had a similar moment yesterday while thinking about Max Allen, the interviewer during that CBC show with Ted Nelson where they were talking about computers in 1979.

I wonder if these people ever got to know a bit about the things they didn't understand at the time. I also wonder if I'll ever get to know about the unknown unknowns in my life :)

Re: Massacring C Pointers

#69

Post by narag »

stinos wrote: post #60
narag wrote: post #51

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too. I can't warn you bec…

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.

Re: Massacring C Pointers

#70

Post by setquk »

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 with a high level of scepticism and get your info from more than one source (textbook) and find out which ones were reputable and which ones were garbage.

Basically there was a monolith in the middle of the course, a crap textbook, and monkeys were praying to it as the authority on everything.

Post reply on HN