I believe these appeared at least in glibc 2.27 (and POSIX 2001), if not earlier, and they run at runtime.
I'm not sure how legal it would be for the compiler to handle things in this way (apart from in "implementation defined" areas), but there isn't a technical reason they can't allocate executable memory at runtime.
(I also believe Windows handles things similarly with VirtualAlloc & VirtualProtect).
Many platforms won't let you allocate memory with both PROT_WRITE and PROT_EXEC. More portable JIT engines either map memory writable to write out code and then remap it read-only and executable before executing it, or map the same memory into two separate virtual addresses, one writable and one executable.
Yes, it cannot be done in a platform-independent way. That's normal for quite a range of things that C is still more than capable of doing.
quadmath isn't supported by every architecture or platform. That doesn't mean the compiler is stuck and can't make use of it on the platforms that do support it.
> Whilst this can't be done in a platform-independent way, C does allow you to do this, doesn't it?
Whilst this can't be done in a platform-independent way, C does allow you to do this, doesn't it?
(Or by mmapping and then calling mprotect).I believe these appeared at least in glibc 2.27 (and POSIX 2001), if not earlier, and they run at runtime.
I'm not sure how legal it would be for the compiler to handle things in this way (apart from in "implementation defined" areas), but there isn't a technical reason they can't allocate executable memory at runtime.
(I also believe Windows handles things similarly with VirtualAlloc & VirtualProtect).