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

201–210 of 300 posts

Re: Massacring C Pointers

#201

Post by int0x80 »

simias wrote: post #191
jschwartzi wrote: post #187

Earlier quoted context omitted.

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" la…

Absolutely. strncpy is a very badly designed interface. Is it documented? Yes. Does that make it any good? No.

Principle of least surprise. Idiot proof. Semantics that match common usage. Call it what you like.

Re: Massacring C Pointers

#202

Post by _8j50 »

saagarjha wrote: post #18
_8j50 wrote: post #11

Earlier quoted context omitted.

There are a few bugs in it. It returns something on the local functions stack (r) which gets torn down after return. It uses the insecure strcpy allowing the caller to stack overflow the destination. It increments t in the loop after dereferencing it which only changes the value pointed to by t. x and y are improperly initialized, it null terminates r without checking for x's value(again a buffer overflow) and there…

> x and y are improperly initialized How so?

I said that because I forgot the strlen was there. I was wrong.

Re: Massacring C Pointers

#203

Post by minipci1321 »

blt wrote: post #189
minipci1321 wrote: post #35

Earlier quoted context omitted.

> 5. 'strcpy' should usually be replaced by 'strncpy'... That prevents a class of exploitable errors known as "buffer overruns". To be honest, strncpy is barely better in this respect (as a security improvement) - truncating against arbitrary size limit in this day and age of text-only protocols... I wonder if outright crashing at the testing stage would be preferable rather than subtle misbehavior creeping into the…

Raw null terminated strings are just a bad idea. `std::string` and the bafflingly just-introduced `std::string_view` are the right way to handle strings. We can spare the bytes now.

> Raw null terminated strings are just a bad idea.

Absolutely agree. Scanning the memory until "we find it", potentially crossing boundaries between segments of memory with different characteristics (caching etc.) just doesn't seem right in general, and if I recall, some CPUs even used to have published errata related to that.

> std::string` and the bafflingly just-introduced `std::string_view` are the right way to handle strings.

I'd even go straight to custom implementation of Hollerith strings. Literals have lengths known at compile time, protocols would either carry the lengths alongside the strings, or be trusted (to have good strlen behavior) until they do, composite strings would compute the length out of the components, etc. This doesn't seem too complex to do, looking from from my bell tower, but I know many people here would frown upon mentioning C++ in the context of embedded development (my area).

Re: Massacring C Pointers

#204

Post by int0x80 »

kevin_thibedeau wrote: post #192
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…

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.

Agree.

Re: Massacring C Pointers

#205

Post by maxlybbert »

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…

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

Re: Massacring C Pointers

#206

Post by tho09823ntaoent »

pjmlp wrote: post #103
dinglejungle wrote: post #77

Earlier quoted context omitted.

Might be totally wrong, but it's possible that MSVC++ programmers typically knowing 'C with classes' might come from the gaming world, as that's a fairly accurate description of some very popular game engines (Valve's Source engine[1] being the one I'm most familiar with, where e.g. std::string is unused in favor of char/wchar arrays). [1] https://github.com/ValveSoftware/source-sdk-2013 (originally released in 2004)

It is a bit more complicated than that. C wasn't much used in MS-DOS, as it was yet another systems language trying to gain the place of Assembly for high performance applications. In some countries Pascal dialects (mostly TP compatible), Modula-2 reigned, while in others C and C++ were other contenders. By the time Windows (written in C) became mature enough people started caring about it (3.x), C++ was already havi…

Oh God, Petzold's book. What a piece of trash that was. The code, while not incorrect like the one in the article, was fairly atrocious, and the various UI things he did were unforgivable, if only because it encouraged legions of programmers to completely disregard any human interface principles. If I could erase one CS book from history, that might be the one.

Re: Massacring C Pointers

#207

Post by walshemj »

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.

Re: Massacring C Pointers

#208

Post by klibertp »

pnathan wrote: post #171
nwmcsween wrote: post #39

Earlier quoted context omitted.

The issue with really learning computer science outside top well known schools is that you're basically on your own for education (or worse if taught wrong). Open source software somewhat teaches you things but usually by trial by fire.

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

Re: Massacring C Pointers

#209

Post by _kst_ »

delhanty wrote: post #121
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...

It appears that someone having read your comment here has left a horribly abusive comment on that memorial page now under the handle "Screw You Bob". > ... The Hacker News army is here. "Screw You Bob" you do not speak for me. Hopefully, you don't speak for many people on HN. Words fail me. Can't we let the dead rest in peace?

Fortunately that comment appears to be gone.

Re: Massacring C Pointers

#210

Post by _8j50 »

Figs wrote: post #50
_8j50 wrote: post #11

Earlier quoted context omitted.

There are a few bugs in it. It returns something on the local functions stack (r) which gets torn down after return. It uses the insecure strcpy allowing the caller to stack overflow the destination. It increments t in the loop after dereferencing it which only changes the value pointed to by t. x and y are improperly initialized, it null terminates r without checking for x's value(again a buffer overflow) and there…

> 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.
Post reply on HN