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

121–130 of 300 posts

Re: Massacring C Pointers

#121

Post by delhanty »

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?

Re: Massacring C Pointers

#122

Post by caf »

bcaa7f3a8bbc wrote: post #118

> "Both programs also contain another value of 43. This is the constant that was written directly into the program." (p. 29) — I have no idea what this means. > I believe that the author thinks that integer constants are stored somewhere in memory. The reason I think this is that earlier there was a strange thing about a "constant being written directly into the program." Later on page 44 there is talk about string c…

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.

Re: Massacring C Pointers

#124

Post by ziotom78 »

slashvar2701 wrote: post #107
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…

Where I was teaching, we've started doing code review in classroom in basically the same spirit. The amount of students prevents us from real selection, instead we take exercises which failed tests (and that are not empty) and explain what was wrong, identify common mistakes or bad style and try to make it correct. We had a very good feedback on this. And we saw an evolution in students' code. It was way better than…

This is some very good advice! I am teaching a C++ class and am struggling with the quality of the code my students are producing. Their programs output the correct answer, yet the style is really lacking. Periodic code reviews of some selected problems would be extremely useful, thank you for the tip!

Re: Massacring C Pointers

#125

Post by bcaa7f3a8bbc »

goldenkey wrote: post #119
bcaa7f3a8bbc wrote: post #118

> "Both programs also contain another value of 43. This is the constant that was written directly into the program." (p. 29) — I have no idea what this means. > I believe that the author thinks that integer constants are stored somewhere in memory. The reason I think this is that earlier there was a strange thing about a "constant being written directly into the program." Later on page 44 there is talk about string c…

A constant can simply be part of the actual assembly instructions in the code segment. Depending on what type of constant and how large it is, it might just be inlined instead of using a memory load. Shared use can also be a compiler heuristic, a large constant used 100 times is more likely to be a shared reference instead of inlined.

Accurate. They don't have to be inside the data segment - they can simply be part of the actual assembly instructions. But more or less, it means the constant is "being written directly into the program".

If "program" refers to the object code unambiguously, I don't think this expression is problematic per se.

Re: Massacring C Pointers

#126

Post by mikeash »

blub wrote: post #113
irishsultan wrote: post #109

Earlier quoted context omitted.

This doesn't explain why one would ever want to return a pointer to a local variable.

As mentioned by another commenter, they were probably targeting the Keil C51 compiler which stores local function arguments in fixed memory locations: https://news.ycombinator.com/item?id=17399633

Unless the book states this explicitly and explains that their examples are only good with that compiler and are not actually valid C, that doesn’t really help.

Re: Massacring C Pointers

#127

Post by int0x80 »

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

Yes, I dont like the strncpy interface, it is very error prone. I just gave it as a posibility. But I did refer to the man page and said "various truncation semantics" because of that, precisely, without going into more detail though.

Re: Massacring C Pointers

#128

Post by bcaa7f3a8bbc »

caf wrote: post #122
bcaa7f3a8bbc wrote: post #118

> "Both programs also contain another value of 43. This is the constant that was written directly into the program." (p. 29) — I have no idea what this means. > I believe that the author thinks that integer constants are stored somewhere in memory. The reason I think this is that earlier there was a strange thing about a "constant being written directly into the program." Later on page 44 there is talk about string c…

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.

Re: Massacring C Pointers

#130

Post by jwilk »

gumby wrote: post #82
azernik wrote: post #80

Bad reviews are always so much more fun to read than good ones.

To review your comment: "The author's well meaning and accurate comment is that well-written negative reviews are typically far more fun to read than positive ones of any quality -- in the positive case you usually want to simply read the book, while the implication of the comment is that the pleasure of reading the negative ones is a delicious Schadenfreude . "Regrettably, this insight was obscured by a regrettable…

"Regrettably" and "regrettable" is a single sentence, "comments" instead of "commenter", missing "to" after "ought", lowercase "internet"; all that in a single paragraph. Error density in gumby's English is astounding.
Post reply on HN