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

31–40 of 300 posts

Re: Massacring C Pointers

#31

Post by oldcynic »

saagarjha wrote: post #23
oldcynic wrote: post #19

Make sure to click the link at the end of the article for code samples with potential for Segmentation fault:core dumped in 4 lines. Even more concerning is the book seems to have some positive reviews on Amazon(!), and just one shredding it.

The example given at the top of the article can cause a segmentation fault. See the other comments here for how.

Returning out of bounds pointers will do that. Was more impressed by the range of errors in his 4 line examples - the sort of thing you'd expect from a struggling student not a tutor or author. :)

Re: Massacring C Pointers

#32

Post by patrickyeon »

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 wrong answer". And then she would work through why she liked it so much with the students. In the examples, it was cases where the person was on the right track, but then made an incorrect, but justifiable by _some_ standard, step in solving it.

It seemed like a good way to really try to understand where someone's comprehension broke down. It felt like it added some legitimacy to the students who got the answer wrong, if others could look at it and go "oh, I see why you thought that!" instead of just "wow try to get it right next time". I believe it's part of what good teachers (not limited to school educators, mind you) are doing all the time: looking for the student's gaps and trying to correct those, instead of just repeating the lesson that has already failed to stick.

I guess this just makes me think of that teacher, trying to work out what her pupils were misunderstanding, by looking at their answers.

Re: Massacring C Pointers

#33

Post by jmts »

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…

Not sure why you're being downvoted. That's all pretty standard.

Method 1 is a contract you often make as part of defining the interface. For an example, such things are out of scope so this is a perfectly reasonable point.

Method 2 is common. Most of the strn*() and snprintf() etc, do this. This is the preferred method for some of my colleagues.

Method 3 is used in the standard library, though as mentioned is usually avoided.

Re: Massacring C Pointers

#34

Post by saagarjha »

leodeid wrote: post #28
saagarjha wrote: post #20

Earlier quoted context omitted.

> If the input 't' doesn't have a null terminator Then it's not a string.

Sure, but it is still a valid 'char *' :)

That's something C's type system doesn't check for. If you want protection for this case, use C++ or any other higher-level language instead.

Re: Massacring C Pointers

#35

Post by minipci1321 »

leodeid wrote: post #17
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…

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…

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

Both are bad IMO, the actual required buffer size should be known in advance.

Re: Massacring C Pointers

#36

Post by saagarjha »

flukus wrote: post #30
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…

> Can someone please elaborate why it is bad? Are their any good resources to fill gaps in my knowledge? If you're actually learning C and writing programs in it then the two best things to do would be turn compiler warnings up to 11 and run valgrind often. So you want -Wall and -Wpedantic when you compile and if possible run with valgrind as part of your build script or run it with your tests, just run it often (the…

Or -fsanitize=address, if your OS does not support Valgrind.

Re: Massacring C Pointers

#37

Post by saagarjha »

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…

I'd suggest not insulting the people reading your comment if you want some points back…

Re: Massacring C Pointers

#38

Post by caf »

jmts wrote: post #27
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…

Most of these points are covered by the other comments. As a C programmer professionally, I'll go into a little more depth, and offer an alternative implementation for comparison. The function in question: char *combine(s, t) char *s, *t; { int x, y; char r[100]; strcpy(r, s); y = strlen(r); for (x = y; *t != '\0'; ++x) r[x] = *t++; r[x] = '\0'; return(r); } 1. The array 'r' is allocated on the stack, and returned fr…

You can avoid the need for setting the null terminator explicitly by using memcpy(str + slen, t, tlen + 1) as the second memcpy.

Re: Massacring C Pointers

#39

Post by nwmcsween »

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…

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.

Re: Massacring C Pointers

#40

Post by nwmcsween »

saagarjha wrote: post #34
leodeid wrote: post #28

Earlier quoted context omitted.

Sure, but it is still a valid 'char *' :)

That's something C's type system doesn't check for. If you want protection for this case, use C++ or any other higher-level language instead.

Well to be pedantic C++'s type system doesn't check for that either it just passes around a size_t and char *.
Post reply on HN