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

111–120 of 300 posts

Re: Massacring C Pointers

#111

Post by feintruled »

oblio wrote: post #68
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...

Damn, that's sad. I had a similar moment yesterday while thinking about Max Allen, the interviewer during that CBC show with Ted Nelson where they were talking about computers in 1979. I wonder if these people ever got to know a bit about the things they didn't understand at the time. I also wonder if I'll ever get to know about the unknown unknowns in my life :)

What's also sad is some idiot went there from that link and left an abusive comment on his memorial website referencing Hacker News. Pretty pathetic, whoever did that.

Re: Massacring C Pointers

#112

Post by mikeash »

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.

I went to an unknown state school and I got a damned fine education. Top schools don’t have a monopoly on good teachers or good students, not even remotely close.

Re: Massacring C Pointers

#113

Post by blub »

irishsultan wrote: post #109
bitL wrote: post #101

Earlier quoted context omitted.

Back in those days 100 bytes was like a huge string; when you raised your hands that there will be a problem you were told to shut up, that you don't get the efficiency of computing and that you won't see strings longer than 16 characters or similar. This Zeitgeist is completely lost and viewing it with contemporary optics is just funny at best. IIRC most of early hacks on Internet exploited the lack of boundaries in…

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

Re: Massacring C Pointers

#114

Post by jmts »

userbinator wrote: post #93
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 know there are already plenty of comments about the problems but might as well give mine too... In one sentence: this guy managed to reinvent a variant of strcat and get it completely wrong. Here's a somewhat better version: char *combine(char *s, char *t) { size_t m = strlen(s), n = strlen(t); char *ret = malloc(m + n + 1); if(ret) { memcpy(ret, s, m); strcpy(ret + m, t); } return ret; }

You already know the length of t. strcpy is inefficient when another memcpy will do.

Re: Massacring C Pointers

#115

Post by simias »

jmts wrote: post #110
simias wrote: post #63

Earlier quoted context omitted.

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

Documented behaviour is a little different to "effectively broken". The difference between strncpy and strlcpy is that strlcpy will NUL terminate the last byte for you always. There is nothing stopping you from doing the same thing yourself when you use strncpy. If you care enough, write your own strlcpy - it's only one extra line.

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 then it ought to notify it somehow, for instance by returning NULL in such a case. And even then it's incoherent with snprintf which doesn't have the same behaviour and does always terminate with '\0' even in case of truncation (assuming non-0 buffer length, of course).

It's just an unnecessary footgun that serves no practical purpose. It would be like a date function that gives you the today's date except on the 4th of December where it replies that it's the 31st of February. Not hard to work around but still broken.

Re: Massacring C Pointers

#116

Post by jmull »

stinos wrote: post #60
narag wrote: post #51

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too. I can't warn you bec…

He was a former BASIC book author too Hmm, I'm starting to see a pattern. Is it possible BASIC, plus lack of internet back in the day, plus attrocious books are the reasons for truning poeple into terrible programmers? I happen to know only a couple of seniors but without exception their code, no matter what language written in today, is horrible on all fronts. I used to think it was a lack of attention to detail, th…

You have only two data points, and obviously the second data point (the post you’re responding directly to) was remembered and posted because of its similarity to the main article, which is anything but an independent data point.

I think your conjecture is based on confirmation bias and a bad experience you’ve had with some colleagues.

Re: Massacring C Pointers

#118

Post by bcaa7f3a8bbc »

> "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 constants and "setting aside memory for constants." I'm wondering now…

Yes, most of the book is wrong. In this example, the author probably also presented this idea in a wrong way.

But the author is correct for having the idea that "constant being written directly into the program" (by the compiler!) and "integer constants are stored somewhere in memory", they are correct and make perfect sense. Of course the integer constants and string constants are all allocated and stored somewhere in memory (or somewhere that can be mapped as memory). They are usually known the text segment and data segment.

> …(remember, the array name becomes a pointer when used without the subscripting brackets)"

> "…while a pointer, as always, is a special variable that holds the address of a memory location." (p. 57) — Still wrong, but slightly less wrong.

Good enough IMHO. It is true that an array "name" is a pointer to its base address.

Re: Massacring C Pointers

#119

Post by goldenkey »

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.

Re: Massacring C Pointers

#120

Post by goldenkey »

feintruled wrote: post #111
oblio wrote: post #68

Earlier quoted context omitted.

Damn, that's sad. I had a similar moment yesterday while thinking about Max Allen, the interviewer during that CBC show with Ted Nelson where they were talking about computers in 1979. I wonder if these people ever got to know a bit about the things they didn't understand at the time. I also wonder if I'll ever get to know about the unknown unknowns in my life :)

What's also sad is some idiot went there from that link and left an abusive comment on his memorial website referencing Hacker News. Pretty pathetic, whoever did that.

I think I speak for all the developed brains on this website when I say that defacement is pathetic and weak, clearly coming from an impotent individual.

Rest in peace Mr. Traister, we love you even though C kinda thorned ya. :-)

Post reply on HN