- assumes x86_64

- makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it)

- assumes (as the article acknowledges) that “to determine the length of foo(), we added an empty function, bar(), that immediately follows foo(). By subtracting the address of bar() from foo() we can determine the length in bytes of foo().”. Even simple “all functions align at cache lines” slightly violates that, and I can see a compiler or a linker move the otherwise unused bar away from foo for various reasons.

- makes assumptions about the OS it is running on.

- makes assumptions about the instructions that its source code gets compiled into. For example, in the original example, a sufficiently smart compiler could compile

  void foo(void) {
    int i=0;
    i++;
    printf("i: %d\n", i);
  }

  void foo(void) {
    printf("1\n");
  }

  void foo(void) {
    puts("1");
  }

Also, why does this example work without flushing the instruction cache after modifying the code?

The only way to do this now on macOS is remapping whole pages as JIT. This makes it quite a challenge but still it might work…

Also, I spent a moderately successful internship at Microsoft working on dynamic assemblies. I never got deep enough into that to fully understand when and how customers where actually using it.

https://learn.microsoft.com/en-us/dotnet/fundamentals/reflec...