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

Post by steveklabnik » Wed, Oct 18, 2023, 12:23 AM UTC

ecshafer wrote: post #61

zh3 wrote: post #55

Earlier quoted context omitted.

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

I think a more accurate analogy would be some kind of scalpel that would not let the surgeon cut deeper than they needed. So if they needed a 1 cm incision, it would somehow stop the blade form going in 1.1 cm. In that case, some experienced surgeon may say "But I know how to make a 1cm incision!", but I think that the reality is that preventing a mistake from happening is valuable. You see the same arguments against…

Post by jfbastien » Wed, Oct 18, 2023, 12:27 AM UTC

sacnoradhq wrote: post #12

This statement would be technically legal on its own in x86 real mode if the compiler didn't do null pointer checks. However it would set the divide-by-zero IRQ handler to itself 0000:0000, and when the next division by zero happened, the machine run into UB (likely a reset or halt) because it would jump there, do 4x ADD byte ptr [BX + SI], AL (or ADD byte ptr [EAX], AL) followed by running the remaining interrupt ve…

Post by pests » Wed, Oct 18, 2023, 12:33 AM UTC

dbrower wrote: post #27

sacnoradhq wrote: post #16

Earlier quoted context omitted.

Find me one contemporary example (ANSI C) with a disassembled screenshot. This is writing sizeof(char) (== 1 almost everywhere) zero to address zero. It is not using a NULL macro or other predefined symbol. In the real world, this would generally write a byte to address 0000:0000, leading to UB because it would fuck up the divide-by-zero IV. PS: I used Borland C++ 3.1, Microsoft C++ 3.x and 4.5x, Watcom, and early GN…

It doesn't have to be the NULL macro, which is correctly defined as plain 0. The literal 0 is treated specially, so this could indeed be one of those 'turns into a weird bit pattern NULL pointers', if such a thing existed in the wild anymore. But you're correct in that there probably haven't been any since the turn of the century or whenever the last Univac mainframes got turned off.

    execl takes a variable-length, null-pointer-terminated list of character pointer arguments, and is correctly called like this:
    execl("/bin/sh", "sh", "-c", "date", (char *)0);

Post by AlotOfReading » Wed, Oct 18, 2023, 12:37 AM UTC

sargstuff wrote: post #50

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…

yes, compiler will align integers on word boundaries. casting to char, just uses the first 8 bits of integer word. Char was originaly just sematic macro for integer. pointer to char is 8 sequenial bits somewhere in the group of integer spaced bits. if you're lucky, the 8 bits are at the start of the integer group of bits, otherwise, segfault. Originaly using anonymous unions & placing largest bit count variable as fi…

Post by junon » Wed, Oct 18, 2023, 12:44 AM UTC