Before I watch the full talk for the answer (what I've seen so far, he states there's not a right answer)...

I know on some microcontrollers (e.g. Arm) addresses 0x0 and 0x4 are usually used to define the initial stack pointer and entry point and then are never needed again.

Later, you probably want to detect the presence of null pointers by checking if &maybeAStruct is either 0 or valid. If you accidentally test the value at that address, you'll get a non-zero and then run code you didn't intend to run. By defining address 0x0 as value 0, you'll avoid this issue. That has two problems.

Alternatively, you define address 0x0 to erase the initial stack pointer so that a nefarious actor can't somehow memory dump and then find out where the program starts its execution. I don't see the benefit for several reasons.

-----

Scenario 1.

The first problem is that you shouldn't write code poorly. If you meant to check a variable's address and instead check its value, that's on you, your test suite, your compiler, and your debugger (and by extension, your colleagues and educators).

Second, writing to address 0x0 on a Cortex usually involves writing to flash... which is not a temporary/nonpersistent change, more involved than simply writing to an address (you usually need to enable the flash controller and set some peripheral registers), and would usually not be allowed on a production device because that's where the bootloader is or that section of memory has been write protected following good practices.

Scenario 2.

The more I think about this one, the less it makes sense. Anyone with debug port access or a memory dump is already inside the castle, well past any defenses e.g. zeroing the main stack pointer. Plus, the same caveats from Scenario 1 apply: if you COULD write to 0x0, it is almost always a terrible idea.

-----

Grand takeaway? This is probably a talk relevant to PC and not embedded. A Cortex-M would definitely complain about this code. Even on an AVR (atmega) changing 0x0 would be changing R0. I don't even know if that register is directly writeable during execution---probably because it's how you set some bootloader bits---but it's definitely dangerous.

With that in mind, I searched for "virtual address space windows" to figure out what goes in an executable at address 0x0. After reading Microsoft's first two articles, it's still unclear what goes in 0x0. Wikipedia? No answer. Next result? Nothing.

Finally, a page about Windows ME/98/95 states address 0x0 is "available to the process" but is "not writable".

After ten more minutes of fruitless searching, I'm willing to just test what happens, because I expect that's not even writable without side effects during execution.

#include <iostream>
int main() {
*(char*)0 = 0;
std::cout << "test" << std::endl;
}

and then, "g++ test.cpp -o test", and ...

[1] 869 segmentation fault ./test

Linux? Fail.

-----

"cl test.cpp /link /out:test.exe"...

This compiles and runs but does not display the test string. (If you remove the 0x0 assignment, the string displays; no surprise)

Interestingly, I can't delete test.exe right away. It has stayed open:

ERROR: The process with PID 12776 (child process of PID 19728) could not be terminated.

Not only does PID 19728 not exist, I have to use an administrator console to "taskkill test.exe", so this would probably never belong inside user space code on Windows.

-----

Thus, this short code snippet seems like trouble, and the answer I would hope for as an interviewer is, "yeah, I don't write code like that, sorry."

(Coincidentally, I would say the same in response to the professors giving microcontroller exam questions that try to stump students with multiple casts and dereferences in a single line *ahem Moreno*. Stop teaching students methods they will never, ever use in a shop that cares about its code!!)

Now I watch and learn.