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

151–160 of 300 posts

Re: Massacring C Pointers

#151

Post by mikeash »

bitL wrote: post #135
mikeash wrote: post #126

Earlier quoted context omitted.

Unless the book states this explicitly and explains that their examples are only good with that compiler and are not actually valid C, that doesn’t really help.

Why would you assume the book author (if he indeed used Keil C51) would be aware of more dialects and their intricacies? Do you really think that in the early 90s there was a wide-spread rigor in software books? There was no Internet, whatever software one could get was the one that was their "standard", there was very limited knowledge exchange between academia and practitioners etc.

I’d assume that because he wrote a book about “C”, not about “C targeted for the Keil C51 compiler.”

I read plenty of programming books around that time. They were almost always specific to some platform, but they always said so. I never saw, say, a “Pascal” book that turned out to be completely specific to ORCA/Pascal. It would say what it was for.

Re: Massacring C Pointers

#152

Post by npsimons »

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…

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

Ironically, I think this is one of the best lessons anyone can learn . . .

Re: Massacring C Pointers

#153

Post by beojan »

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…

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

Re: Massacring C Pointers

#154

Post by saagarjha »

colejohnson66 wrote: post #133
ChrisSD wrote: post #47

Earlier quoted context omitted.

C11 introduced strnlen_s, a "safe" replacement to strlen.

What’s safer about it? Doesn’t `strlen' just scan until the null character, then go nullCharPtr - str ? Is there something unsafe with that?

strnlen_s takes a parameter for the maximum number of characters to scan. This way, it won’t overflow the buffer you provide it if there’s no trailing null byte.

Re: Massacring C Pointers

#155

Post by mikeash »

icedchai wrote: post #134
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…

Keep in mind BASIC was the most accessible language in the 80's. Almost all computers shipped with basic... It was like today's Javascript.

I think the JS comparison undersells it. Many computers would literally drop you into a BASIC prompt at boot. I remember my first encounter with MS-DOS and finding it weird that you had to actually run a program to get to BASIC.

Re: Massacring C Pointers

#156

Post by optimuspaul »

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…

One of the reasons I don't consider a degree anything of value when evaluating candidates. It might be a baseline or it might be a red herring. Best to just assume a degree and no degree are equal and asses based on practical examples.

Re: Massacring C Pointers

#157

Post by icedchai »

mikeash wrote: post #155
icedchai wrote: post #134

Earlier quoted context omitted.

Keep in mind BASIC was the most accessible language in the 80's. Almost all computers shipped with basic... It was like today's Javascript.

I think the JS comparison undersells it. Many computers would literally drop you into a BASIC prompt at boot. I remember my first encounter with MS-DOS and finding it weird that you had to actually run a program to get to BASIC.

Yes, you are absolutely correct! BASIC seemed much more accessible on early microcomputers, when compared to any programming language today. Basic essentially was the OS. The Apple II, C64, etc. extended basic with DOS-like commands. They often shipped with BASIC manuals!

Re: Massacring C Pointers

#158

Post by dxhdr »

simias wrote: post #115
jmts wrote: post #110

Earlier quoted context omitted.

Documented behaviour is a little different to "effectively broken". The difference between strncpy and strlcpy is that strlcpy will NUL terminate the last byte for you always. There is nothing stopping you from doing the same thing yourself when you use strncpy. If you care enough, write your own strlcpy - it's only one extra line.

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 agree it's terribly named, however discussing the behavior of strncpy is important because the casual reader or new C programmer will see "don't use strncpy, it's broken" and then come away with the wrong idea. strncpy is not inherently broken but it's most likely not the correct function to use. As a C programmer it's important to understand why and what the alternatives are (and there are several).

Re: Massacring C Pointers

#159

Post by wruza »

simias wrote: post #115
jmts wrote: post #110

Earlier quoted context omitted.

Documented behaviour is a little different to "effectively broken". The difference between strncpy and strlcpy is that strlcpy will NUL terminate the last byte for you always. There is nothing stopping you from doing the same thing yourself when you use strncpy. If you care enough, write your own strlcpy - it's only one extra line.

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…

If you had to name it according to unix traditions, how would you?

Re: Massacring C Pointers

#160

Post by jerf »

LambdaComplex wrote: post #150
jerf wrote: post #146

Earlier quoted context omitted.

There's a sense in which the hardest programming language you'll ever learn is actually your second one. I think the reason for this is that with just one language under your belt, you have very little ability to distinguish between the abstractions the programming language offers you and the capabilities of the machine, and to distinguish between the abstractions the programming language offers you and the capabilit…

> I've interviewed a number of people who think that Java === computing. Not even the "JVM", mind you, but Java, the language, itself. Could you elaborate on this? What exactly made you realize that was how/what they thought?

I had to ponder on what it is that really sets this sort of person apart, and I think it's the sort of sneering disdain at the idea that any of the other languages in the world are worth anything, or have any good ideas. Or maybe it's the way that when you ask them what's good or bad about some other language, you get back just a list of differences those languages have with Java, and it is simply assumed that all differences are ways in which they are inferior to Java.

And let me say again that it's not specifically Java. I've seen a couple of people that way with C, for instance, though not in an interview situation.

Post reply on HN