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

191–200 of 300 posts

Re: Massacring C Pointers

#191

Post by simias »

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.

If the sledgehammer defaults to "leg breaking mode" then it's broken. How often do you actually use strncpy actually intending it not to return a non-NUL terminated string on truncation?

I hate this mentality in a lot of C circles that boils down to "there's no bad language, just bad programmers, man up pussy". I like C, I use it a lot, it's one of the first languages I learned and it's been my main "professional" language for more than a decade. Yet I can also see that it has many unnecessary sore points. Having switch not break by default, gets(), array shenanigans, some aliasing rules, the hundreds of completely different meanings for "static", macro hygiene and I could go on... You can say "it's not a big deal and it's not going to change at that point anyway" and sure, I'm not arguing for a revolution, but let's not act that it's an absolutely perfect language and I'm an idiot that doesn't get it for pointing out these issues.

Re: Massacring C Pointers

#192

Post by kevin_thibedeau »

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…

Friends don't let friends use strncpy(). It doesn't guarantee NUL termination and wastes time zero-padding when it is rarely desired. Use C11 strncpy_s() or platform specific equivalents.

Re: Massacring C Pointers

#193

Post by mannykannot »

bitL wrote: post #185
mannykannot wrote: post #182

Earlier quoted context omitted.

You are defending 'Mastering C Pointers' on the grounds that K&R was outdated ?

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 instant it was written.

Re: Massacring C Pointers

#194

Post by krylon »

This reminds me of the first textbook I tried to learn C++ from. It was fun to read, because the authors seemed to put more energy into writing Limericks than explaining object-oriented design. I don't think it touched on inheritance, and things like, I don't know, inline functions or templates were not mentioned at all.

It did not even contain working example programs, let alone exercises. It was so bad, as the saying goes, it was not even wrong. I still have that book on my shelf as a reminder to not blindly buy the first/cheapest textbook I can find.

Re: Massacring C Pointers

#195

Post by tetha »

patrickyeon wrote: post #32

A few years ago, I saw a classroom video (I would guess ~8-10 year olds, in the American public school system) as a demonstration of a teacher's technique called "my favourite wrong answer". She would have them solve a problem (a math problem, in this particular case), collect the answers, show the distribution of the answers, and then pick out one answer (possibly with the student's name redacted) as her "favourite…

Now you're making me think about my specification and verification professor from years ago. A lot of the exercises had us specify stuff with some formalism. Something like a finite state machine for a 3 digit combination lock, or pre- and post conditions of algorithms, loops and such.

The tutorials about these exercises were really cool, because we'd spend a short time wrapping up mistakes in the notation. But then he usually classified and grouped the different solutions according to the design decisions made and it would evolve into large discussions about tradeoffs of choices.

Someone might go "Well I figured the FSM would be smaller if I fail on the first wrong number, and it'd be user friendly because it fails early", and someone objects "But that's insecure!" and someone else figures "And also it'd be much easier to write up a control circuit that always expects three digits" and eventually everyone is confused if we're looking at the user input as a stream of tuples of three digits, instead of looking at the last three digits in a stream of digits.

It was a very instructive class.

Re: Massacring C Pointers

#196

Post by krylon »

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…

> snprintf (C99+)

It's been years since I have written C professionally (and I only did it for two years), but I felt that snprintf was the single biggest improvement that C99 brought to the table, at least for people that had to deal with strings. ;-)

Re: Massacring C Pointers

#197

Post by heisenbit »

caf wrote: post #131
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…

It's not broken, but it is misnamed. This is because it is not intended to work with the same kind of string that the other str* functions work with (ie. an ordinary null terminated string). Instead it's supposed to work with fixed-width string fields that pad out values shorter than the field width with nulls. This is how original UNIX directory entries were stored. See how the name is copied into u.u_dbuf here: htt…

A misname that may have cost cost billions in bugs and security issues.

Re: Massacring C Pointers

#198

Post by xfer »

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…

This hasn't been my experience in CS, the research professors teaching courses were interested in teaching, the only thing the grad students do is grade assignments/exam papers.

> Reason being anyone talented in CS can make 2-3x the salary out in the real world and so CS grads rarely stick around to teach.

I would call bullshit on that, money is not the only thing that motivates people to do things.

Re: Massacring C Pointers

#199

Post by ChrisSD »

beefhash wrote: post #181
ChrisSD wrote: post #47

Earlier quoted context omitted.

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

strnlen_s is in Annex K, which is an optional part of the standard. Incidentally, no libc in widespread usage has implemented it.

True. The non standard strnlen is however more widespread. Microsoft implements strnlen_s in terms of strnlen like so.

    _String == 0 ? 0 : strnlen(_String, _MaxCount)

Re: Massacring C Pointers

#200

Post by ZephyrP »

bitL wrote: post #98
pjc50 wrote: post #90

Earlier quoted context omitted.

No, all of that example was malpractice in the 80s when it was written. Note the context: it's highlighted as malpractice in a talk by Brian Kernighan!

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…

> I'll bite: argument from authority can be reversed - if Brian didn't mess up the language design, these sort of "code drivels" wouldn't have appeared

i dont know, awk has its faults -- but blaming it for C?

Post reply on HN