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

231–240 of 300 posts

Re: Massacring C Pointers

#231

Post by msla »

bitL wrote: post #229
msla wrote: post #221

Earlier quoted context omitted.

> if Brian didn't mess up the language design, these sorts of "code drivels" wouldn't have appeared! OK, ignoring the s/Brian/Dennis/ snafu... WTF is a "code drivel"? What are you trying to say here? Second, your point is irrelevant: It's pointless to write a book about driving cars and fill it with a long rant about how riding motorcycles is so much better. It's a non sequitur , and false advertising. Much like how…

I love intellectual debates, but this really isn't one. I just have the feeling this is an "intellectual" mob in progress. BTW, it's wonderful to attack people for their English skills; I speak 8 languages but not all of them at C2 level, despite being grad at one of top US colleges. Would you take my sincere apologies for offending you by not being on your level?

I get the impression that you're using odd phrasings deliberately, to obfuscate a point too weak to stand on its own, and to avoid responding to the points of others.

Re: Massacring C Pointers

#232

Post by taserian »

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…

I can speak from my own experience; even though English is my first language, I entered as a grad student and TA in a public US university as a foreigner, since my undergrad degree was done outside the US. After they determined that I was capable of speaking understandable English, they actually made me an instructor of record for a 300-level course that none of the active faculty was available to teach.

It was quite an experience.

Re: Massacring C Pointers

#233

Post by slrz »

saagarjha wrote: post #48
bboreham wrote: post #46

Earlier quoted context omitted.

> '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…

There's strlcpy, but it's not part of POSIX unfortunately.

  #define strlcpy(d, s, n) snprintf(d, n, "%s", s)
Not quite the same (different return type) but close.

Re: Massacring C Pointers

#234

Post by ben509 »

userbinator wrote: post #95
bboreham wrote: post #46

Earlier quoted context omitted.

> '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…

I agree with you completely, and in general think the whole idea of using "safe" string functions with built-in buffer length checking is wrong because it is a solution to a symptom, not a cause. Before writing to the buffer you should've ensured that it's big enough, and decided what to do if it's not, long before actually doing it. In other words, what happens if it's not big enough? These "always use $length_check…

> Before writing to the buffer you should've ensured that it's big enough, and decided what to do if it's not, long before actually doing it. In other words, what happens if it's not big enough?

If you planned all this out, you're still making an assertion as to the length. The contract is "give me a string of this length" and if that's not enforced by the compiler, it ought to be enforced at runtime so that the error is detected and dealt with as soon as possible.

So maybe "safe string functions" should really be "fail fast string functions."

Re: Massacring C Pointers

#235

Post by klibertp »

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…

> I think he took it with more grace than I deserved.

You mean he gathered all of his students, colleagues, and superiors; officially admitted to faking knowledge where there was none, and solemnly apologized, promising never again to teach things he doesn't understand?

I somehow doubt it, even though teaching nonsense to eager youth from the position of authority is an offense damn close to sexual molestation of minors. Dealing with subtly (or not so subtly) twisted minds, and holes (and lies) in knowledge, of the corrupted students happens years later and is someone else's problem, but it's all caused by teachers like this. I don't see anything graceful in it, at all.

Re: Massacring C Pointers

#236

Post by slrz »

ChrisSD wrote: post #144
colejohnson66 wrote: post #133

Earlier quoted context omitted.

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

What if there is no null?

Then you probably shouldn't feed it to the str* functions at all. Use the mem* functions instead.

Re: Massacring C Pointers

#237

Post by RobotCaleb »

walshemj wrote: post #207
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…

Reminds me of when I was 15 and the teacher we had the previous year had left and one of the maths teachers took over. He did his best but I have taught my self faster than he did. Though because I was on the CSE stream even though I got a grade 1 they wouldn't let me do computing at A level - as CSE kids where supposed to leave at 16.

Your last sentence is intriguing to me. I understand all the words, and I think I get the gist, but I'm not familiar with any of it.

What is CSE? Google seems to think it's Certificate of Secondary Education. So, middle school -> early high school equivalent?

Grade 1? A level? Leave where, the school?

(I'm in the US, so that's probably the disconnect)

Re: Massacring C Pointers

#238

Post by erikpukinskis »

klibertp wrote: post #235
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…

> I think he took it with more grace than I deserved. You mean he gathered all of his students, colleagues, and superiors; officially admitted to faking knowledge where there was none, and solemnly apologized, promising never again to teach things he doesn't understand? I somehow doubt it, even though teaching nonsense to eager youth from the position of authority is an offense damn close to sexual molestation of min…

> teaching nonsense to eager youth from the position of authority is an offense damn close to sexual molestation

You really think this?

Re: Massacring C Pointers

#239

Post by pnathan »

klibertp wrote: post #208
pnathan wrote: post #171

Earlier quoted context omitted.

> really learning computer science outside top well known schools Eh... no. It's not 1975 anymore. This knowledge is widely distributed.

Moreover, the on your own for education bit, even if true is a bit dishonest. Being "on your own" with this in 2018 is absolutely incomparable to how it was 10 years ago, much less 20 or more. The amount of materials accessible for free or extremely cheap is mind-blowing to people who had to learn programming from a single (physical) copy of Stroustrup's "The C++ Programming Language".

when I contemplate the available resources for a starting programmer, my mind is always stunned.

Re: Massacring C Pointers

#240

Post by Figs »

_8j50 wrote: post #210
Figs wrote: post #50

Earlier quoted context omitted.

> It increments t in the loop after dereferencing it which only changes the value pointed to by t. This is wrong. Postfix increment has a higher precedence than the dereference operator.

Are you sure? I'll need to test this. Always thought postfix increment and decrement applied after everything else was evaluated,and that's why prefix versions exist.

Yes. Here is a table that lists operator precedence in C: https://en.cppreference.com/w/c/language/operator_precedence

Note that postfix increment is at the highest precedence and the dereference operator is at the second highest precedence.

The postfix operators behave in a bit of an interesting way; the expression "t++" evaluates to just "t" but increments t as a side effect. Consequently, it appears to update t after the expression it is part of, even though it is one of the first things evaluated.

If you actually test the function, you will find that it works provided that you make r static or global instead of a local stack variable -- and, of course, carefully mind the restriction on the length of the input strings to avoid overflowing the buffer.

Post reply on HN