Re: A Famous Security Bug

On 24/03/2024 20:56, bart wrote:

On 24/03/2024 14:52, David Brown wrote:

On 23/03/2024 22:21, bart wrote:

 

 

This works on DMC, tcc, mcc, lccwin, but not gcc because that loads programs at high addresses. The problem being that the address involved, while belonging to the program, is outside of any C data objects.
>

>
I think you are being quite unreasonable in blaming gcc - or C - for generating code that cannot access that particular arbitrary address!

 There were two separate points here. One is that a gcc-compiled version won't work because exe images are not loaded at 0x40'0000.

I think that is because your gcc toolchain is creating 64-bit Windows binaries, while the others are creating 32-bit binaries.  I could be wrong here, of course.

The other was me speculating whether the access to 0x40'0000, even when valid memory for this process, was UB in C.
 

Trying to access non-existent memory is UB, yes.  I can't imagine a language where such a thing would be anything else than undefined behaviour, or defined as a hard run-time error.
But you can run something with UB if you want - at your own risk, because C and the compiler give you no guarantees of what will happen. But if you write "x = *(volatile uint8_t *) 0x400000;", then you can guarantee that the code will at least /try/ to read that address.  What happens depends on the OS, memory protection systems, etc.  But it is not exactly difficult to do this kind of thing in C - that's why "volatile" exists.