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

171–180 of 300 posts

Re: Massacring C Pointers

#171

Post by pnathan »

nwmcsween wrote: post #39
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.

> really learning computer science outside top well known schools

Eh... no. It's not 1975 anymore. This knowledge is widely distributed.

Re: Massacring C Pointers

#172

Post by bitL »

mannykannot wrote: post #169
bitL wrote: post #135

Earlier quoted context omitted.

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.

In the 90's there was at least one good software book: 'The C Programming Language' by messrs. Kernighan and Ritchie - you may have heard of it? It correctly told you, among other things, everything you really need to know about using pointers in C. It is still available.

I was a kid back then; K&R was pretty hard to find in my area and it was quite outdated anyway, most people were happy to use whatever resources they could get; the best in mid-to-late 90s ended up things like what DJ Delorie wrote, stuff from John Carmack, Dave Eberly etc. that were pretty low on rigor but very high on practical value.

Re: Massacring C Pointers

#173

Post by jwilk »

leni536 wrote: post #72
ZephyrP wrote: post #3

I always wondered about the C tutorials Brian Kernigan mentions in his talk ( https://www.youtube.com/watch?v=8SUkrR7ZfTA ) , many of the examples seem intentionally designed to be incorrect by some trickster spirit. Now I know the even darker truth.

The exact same code sample appears in the talk as in the article.

Yes, the article mentions the sample was taken from the talk.

Re: Massacring C Pointers

#174

Post by qubex »

klodolph wrote: post #143
eesmith wrote: post #74

Earlier quoted context omitted.

To be fair, he said that about a lot of mainstream languages back then. That quote is from EWD498 at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW... . The larger context is (the rest of the comment quotes him): FORTRAN —"the infantile disorder"—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expen…

Having a discussion with someone who quotes Dijkstra can be frustrating. He wrote Go To Statement Considered Harmful and On the Cruelty of Really Teaching Computer Science and left behind a bunch of pithy quotes to mine besides. You end up having to explain why blanket bans on goto don't make sense, why it really is quite difficult to mathematically prove that a program works, or why it makes sense to teach students…

The dicta of Dijisktra should be handled with the same accommodation of self-contradictory paradox as is accorded to zen koans.

Re: Massacring C Pointers

#175

Post by 8xde0wcNwpslOw »

bcaa7f3a8bbc wrote: post #128
caf wrote: post #122

Earlier quoted context omitted.

It is true that an array "name" is a pointer to its base address... No, it's not. It is true that an expression of array type, when it is not the subject of either the unary-& or sizeof operators, evaluates to a pointer to the array's first element. sizeof array gives the size of the whole array, not the size of a pointer. &array gives the address of the whole array, not the address of a pointer.

I've programming under the useful but wrong assumption, that > array[x] and *(ptr+x) is completely equivalent, so array and ptr is equivalent. until now. Thanks for the clarification.

Strictly speaking, the initial part of your assumption is not wrong, but the later conclusion is.

array[x] and *(array+x) are indeed equivalent for any identifiers 'array' and 'x' (assuming one of those evaluates as a pointer value, and the other as an integer value; otherwise the code is incorrect). In fact, in this context an actual array is not subject to either unary-& or sizeof operators, so it evaluates to a pointer value, fulfilling the precondition.

This is why "array subscription" also directly works with pointers (i.e. "ptr[x]"), and from the equivalence above follows one of the common useless facts that you can swap the identifiers (i.e. "x[array]").

(This comment is probably confusing enough without saying that "(&array)[x]" is valid code too, but isn't the same thing as those before.)

Re: Massacring C Pointers

#176

Post by hindsightbias »

klodolph wrote: post #143
eesmith wrote: post #74

Earlier quoted context omitted.

To be fair, he said that about a lot of mainstream languages back then. That quote is from EWD498 at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW... . The larger context is (the rest of the comment quotes him): FORTRAN —"the infantile disorder"—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expen…

Having a discussion with someone who quotes Dijkstra can be frustrating. He wrote Go To Statement Considered Harmful and On the Cruelty of Really Teaching Computer Science and left behind a bunch of pithy quotes to mine besides. You end up having to explain why blanket bans on goto don't make sense, why it really is quite difficult to mathematically prove that a program works, or why it makes sense to teach students…

Dijkstra is the Godwin of Computer Science

Re: Massacring C Pointers

#177

Post by skykooler »

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…

Also, it allocates ints x and y, saves a value to y, copies it to x, and only uses x from then on. y is entirely redundant.

Re: Massacring C Pointers

#178

Post by [deleted] »

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…

[deleted]

Re: Massacring C Pointers

#179

Post by [deleted] »

simias wrote: post #63
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…

You're right, although any mention of strncpy should come with a big disclaimer that it's effectively broken because you can end up with a non-NULL terminated string in some cases. strlcpy should be the way to go but unfortunately it's not part of the C standard and not available everywhere (sometimes for rather bullshit reason IMO, but that's a different story).

[deleted]
Post reply on HN