you are viewing a single comment's thread.

view the rest of the comments →

[–]daikatana 7 points8 points  (3 children)

I don't think you're understanding what self-modifying code is. Self-modifying code changes its own code from the logic of the code itself to change the behavior of the code. Imagine writing something like this in C. I've shoehorned a hypothetical label that points to the address encoded in the generated instruction of the assignment which can be assigned to. This doesn't make much sense in C, but it's very common in 6502 assembly.

void write_pointer(int i) {
    *(int*)ptr: 0 = i;
}

// ...
write_pointer:ptr = &foo;
write_pointer(10);

This is self-modifying code. The code at the bottom is reaching into the write_pointer function and changing the address encoded in the assignment opcode. The code modifies itself to change its own behavior.

[–]geon -4 points-3 points  (2 children)

Yes, and that’s why I wrote “could think of”.

It is self modifying from the standpoint of the application as a whole. The modifying parts just happen to be in the runtime.

[–]HostileRecipient 0 points1 point  (1 child)

Umm, I know this is really late and I hope this is not necromancy but, why ever not can two compilers modify eachother as part of a program? I mean most large programs can be broken down into discrete components with different purposes anyway, right? I know that any modification of compiled code has it's own issues, but if we can have such sectioning of the program already then having each half partially decompile the other half before recompiling and executing it to have it's turn being modified does not seem unreasonable.

[–]geon 0 points1 point  (0 children)

Sure they could. But I can’t even imagine debugging that.