Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

*(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

youtube.com

Post reply on HN
Print view View original

121–130 of 199 posts

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#121

Post by flohofwoe »

dekhn wrote: post #25

When I see that code my head immediately translates to "store a byte with value 0 at memory address zero". 0 the integer needs to be cast to a char * to treat it as a byte address (rather than a word) and the * means "assign to the memory location given by the pointer. I would probably use something like this when hacking on an Apple II with a zero page. I have also written programs that ran on VMS which dumped memor…

> I have also written programs that ran on VMS which dumped memory starting at '0' without getting any segfaults.

That's also totally valid on WebAssembly btw, address 0 is a regular read/write location.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#122

Post by josefx »

flohofwoe wrote: post #120
Kranar wrote: post #118

Earlier quoted context omitted.

You're mostly correct but to be pedantic, in C the literal value 0 does not actually mean address 0. The literal value of 0 is an implementation defined value that represents a null pointer, but that value does not have to be address 0, it could be some other address. This is significant because the following two snippets of code are not required to be equal in C. char* c = (char*)(0); char* d; memset(&d, 0, sizeof(d…

> that value does not have to be address 0, it could be some other address. That's what the spec says, but are there any computers around anymore where nullptr is not zero? The spec should really go with the times IMHO, old hardware can be supported via platform-specific language extensions.

The cleanest way would probably be to get rid of 0 as a null pointer constant, make its use in contexts that expect a pointer illegal and replace it with an explicit keyword. Of course that would break all existing code that uses 0 or (void*)0 instead of NULL, but if you are out to break things anyway you might as well get rid of 40 year old warts.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#123

Post by pjmlp »

zh3 wrote: post #55
vore wrote: post #42

Earlier quoted context omitted.

You say that as if that's a bad thing – I absolutely need to kept safe from myself, because I need all the help I need to make sure I'm doing things right!

I'd agree with that, to the extent that understanding how badly your tools can hurt you is an important thing to learn. Consider how a surgeon would respond if told not to use a scalpel because of the risk of accidental injury when using a sharp tool. We learn from our mistakes - to which I'd add, sometimes we can afford to make mistakes (home programs) and other times we can't (safety-critical code).

That surgeon has undergone several years training, had to go through an exam to be allowed to practice, and is submited to yearly evaluations if they are still allowed to touch that scapel.

I would agree the same for developers, if similar practices would be enforced everywhere instead of having people calling themselves enginners just because they like how the word sounds.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#124

Post by pjmlp »

AlotOfReading wrote: post #74
sargstuff wrote: post #51

Earlier quoted context omitted.

use a malloc that has the extra saftey features, run under an interpreted C, and several other ways to handle it (sandbox program, emulator, etc). Changing the underlying C language should NOT be one of them.

The only way to make C "safe" without modifying the language is to run it in a VM, and even that doesn't fully encompass what people mean by safety. It's an old language. Some of the fundamental mistakes were just things that were common at the time and only look so bad in hindsight (e.g. strings, locales, nullable pointers, half the k&r standard library). That doesn't mean we can't and shouldn't do better where we c…

Example, C++/CLI, if certain code patterns are used the code is no longer considered safe from MSIL verifier point of view.

C and C++ targeting WASM, despite all the security message of how great it is, memory locations inside of the same linear memory segment can still be corrupted, thus providing a way to influence the overall execution logic inside of the sandbox.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#125

Post by Kranar »

flohofwoe wrote: post #120
Kranar wrote: post #118

Earlier quoted context omitted.

You're mostly correct but to be pedantic, in C the literal value 0 does not actually mean address 0. The literal value of 0 is an implementation defined value that represents a null pointer, but that value does not have to be address 0, it could be some other address. This is significant because the following two snippets of code are not required to be equal in C. char* c = (char*)(0); char* d; memset(&d, 0, sizeof(d…

> that value does not have to be address 0, it could be some other address. That's what the spec says, but are there any computers around anymore where nullptr is not zero? The spec should really go with the times IMHO, old hardware can be supported via platform-specific language extensions.

>That's what the spec says, but are there any computers around anymore where nullptr is not zero?

Yeah that's absolutely fair. I actually can't think of a single platform, embedded or otherwise, old or new, where the null pointer is not address 0.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#126

Post by saghm »

lmm wrote: post #102
saghm wrote: post #23

Earlier quoted context omitted.

If I'm understanding what you're saying correctly, the memory location with address 0 is actually a writable address, but with the value being used semantically to handle division by zero? It's kind of wild to me that would even something that's even allowed to be done manually, let alone required by a certain mode. Is this something provided for compatibility reasons that you'd have to opt into, or is it just someth…

Which part is wild? "Magic" memory addresses are a fairly normal way to communicate with hardware; nowadays there are more layers to how you set up mappings in the MMU etc., but in the old days it was normal for everything to just have a fixed address (e.g. I remember back on the Apple ][ the screen's framebuffer was in a particular memory range, or rather two - to avoid tearing you'd draw on one and then flip which…

The part that surprised me is that this would be the way things worked on a modern C++ compiler without any special flags. The article is about C++, and using "magic" memory addresses doesn't seem at all what I'd expect to be the default way to handle division by zero.

From the numerous responses here, it's clear that people interpret my question as about how the hardware itself works, which isn't at all what I was asking about; I'm aware of how stuff like this works at the assembly level, but my understanding was that in C and C++, trying to write arbitrarily to "special" addresses like that would be considered undefined behavior (often resulting in segfaults). When I read the comment I responded to above, it surprised me, so I wanted to check whether I understood what was said correctly. It's honestly kind of confusing to me that so many people seem very upset by the idea that a stranger on the internet might have a misconception about how hardware abstractions are exposed via compiled code to the point that they feel the need to explain in detail how hardware works but not actually answer the question I asked.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#127

Post by pjmlp »

HybridCurve wrote: post #60
cjensen wrote: post #54

Earlier quoted context omitted.

Regarding your PS, I used Borland's Turbo C++ 1.0, and I think you've forgotten that memory models existed. Honestly, that's a good nightmare to forget.

I hated that about DOS, real-mode and BC++. After about 6-8 months of that misery, installing linux and learning to write C code with GCC was the best thing that ever happened to me. I felt like an animal being released from a cage and into the wild.

In those days MS-DOS, Linux was barely usable, when Linux became usable Windows 95 was already around, without those limitations.

My first kernel was 1.0.9 released alongside Slackware 2.0, offering initial support for IDE CD-ROM drives and experimental support for ELF files, by the way.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#128

Post by tetris11 »

tapatio wrote: post #101
yodsanklai wrote: post #62

Not a big fan of the format of the talk. The guy is a good orator, but it takes ages to go to the point. A bit annoying if you're actually interested in the technical part rather than the jokes.

Yup, I’m not going to burn 54 minutes of my life listening to something that should take 30 seconds to convey.

Managers, meet Emails.

Re: *(char*)0 = 0; – What does the C++ programmer intend with this code? [video]

#130

Post by camel-cdr »

flohofwoe wrote: post #120
Kranar wrote: post #118

Earlier quoted context omitted.

You're mostly correct but to be pedantic, in C the literal value 0 does not actually mean address 0. The literal value of 0 is an implementation defined value that represents a null pointer, but that value does not have to be address 0, it could be some other address. This is significant because the following two snippets of code are not required to be equal in C. char* c = (char*)(0); char* d; memset(&d, 0, sizeof(d…

> that value does not have to be address 0, it could be some other address. That's what the spec says, but are there any computers around anymore where nullptr is not zero? The spec should really go with the times IMHO, old hardware can be supported via platform-specific language extensions.

I've seen a compiler that has an alternative null pointer address, but I couldn't find it again.
Post reply on HN