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

161–170 of 199 posts

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

#161

Post by josefx »

gofixurcode wrote: post #155
josefx wrote: post #122

Earlier quoted context omitted.

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.

Ah a new standard! Perfect! Everyone will adopt this as clearly it is better and there’s no reason not to right? … right?

Well it should be backwards compatible if you just use NULL everywhere where it is appropriate, so you wouldn't even have to sprinkle ifdefs all over the place. Code that uses 0 all over the place would probably have to be updated with the help of compiler errors and a static code analyzer.

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

#162

Post by sargstuff »

SilasX wrote: post #103
Kamq wrote: post #63

Earlier quoted context omitted.

I think an even more accurate analogy would be if a surgeon had some kind of scalpel with a 1 cm limit, but if a surgery suddenly changes in the middle, and suddenly requires a deeper incision, the surgeon has to spend a non-zero amount of time re-configuring the scalpel. This casts flexibility vs safety as a tradeoff, which it is.

Oh, one more refinement: Surgeons are constantly killing people[1], and every time, it turns out it was because the surgeon disabled a known, recommended safety rail, and whenever anyone points out that they should stop disabling the safety rails, they insist that they know how to operate without them, it's those other people that don't. Plus it's sooooo inconvenient for an operation[2] to take five more minutes, the…

Was LD_LOAD and related LC stuff (algebra & unix) the 19th c rabbit hole for [1] & [2] ?

1] introducing security vulnerabilities

[2] code changeset submission

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

#163

Post by sargstuff »

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…

Oh, so time of 4k memory, have a 4k program and want to strictly reserve/add 3.14159 K to 4k program for automated saftey issues?

At time C was written, swapping in/out of memory measured in literal minutes & when fraction of second of execution time, including swapping in/out of memory, was more than several times the average yearly salary of the day (excluding sneaker net intervention)

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

#164

Post by [deleted] »

mkup wrote: post #137
saghm wrote: post #126

Earlier quoted context omitted.

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 a…

The difference between modern days and days of DOS isn't in C/C++ compiler, it's in virtual memory and address space isolation and privilege isolation. So it's not a job of a C/C++ compiler to enforce protection from writing to "special" addresses, because interrupt table updates (and memory-mapped hardware I/O in general) still must happen somewhere (i.e. in kernel, hypervisor, drivers etc) and that code is still wr…

[deleted]

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

#165

Post by sargstuff »

mkup wrote: post #137
saghm wrote: post #126

Earlier quoted context omitted.

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 a…

The difference between modern days and days of DOS isn't in C/C++ compiler, it's in virtual memory and address space isolation and privilege isolation. So it's not a job of a C/C++ compiler to enforce protection from writing to "special" addresses, because interrupt table updates (and memory-mapped hardware I/O in general) still must happen somewhere (i.e. in kernel, hypervisor, drivers etc) and that code is still wr…

Mmmm..;. job of modern OS is to use/manage MMU. Prior to DEC, OS just automated version of human feeding punch cards/spooling up tape.

DEC provided the necessary hardware MMU to do actual real time multi-processing/multi-user access in feasibile/practical manner.

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

#166

Post by sargstuff »

lmm wrote: post #136
saghm wrote: post #126

Earlier quoted context omitted.

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 a…

> 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. They're not saying this is, like, a portable standard way to handle division by zero in C++. You're right that it would be undefined behaviour under the standard (but a C++ compiler for real-mode x86 would be expected to support it, at least implicitly; obviously this sp…

> ".. the fact that address 0 is supposed to contain a pointer to the handler .."

What got missed though, is ther has to be an "unused"/"reserve" bit(s) space in order for things to run without requiring additional specific hardware operations.

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

#167

Post by sargstuff »

thombat wrote: post #117
sargstuff wrote: post #9

Earlier quoted context omitted.

http://www.gnu.org/fun/jokes/paging.game.html

That's not just a beautiful high-level description, it's even therapeutic: the next time my HDD is thrashing I'll sit patiently and think that the Page King is too busy ruling his kingdom to grant my humble request right now.

Or being held hostage

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

#169

Post by sargstuff »

junon wrote: post #79

Nothing states NULL is 0x0 (as in bits, not representation). Nothing states the first page (at 0x0) must be empty. It's convention, not rule. (obligatory in C and OS theory, other languages might differ)

Use lisp, cast hex on (). Or use modern version of printf with %p and/or cast hex on NULL macro.

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

#170

Post by sargstuff »

smitop wrote: post #69

fun trivia: in WebAssembly it's valid to read/write to memory address 0.

Ohly because the VM WebAssembly physical hardware address to running program memory address 0 isn't actually mapped to physical hardware memory address 0.

Note: think there's a way to convert this to some shorter, massively recursive C pointer, to pointer .... to pointer declaration explaination.

Post reply on HN