Underhanded C 2015
blog.mattbierner.com
blog.mattbierner.com
Also fortunately, it is standard in the glorious nation of Bob to represent text as an undifferentiated mixture of big-endian UTF-16 and ASCII.
(The floating-point hack is clever, but I find the string quite unconvincing and an obvious place to hide something malicious, and trying to explain it as Unicode doesn't hold up.)
Dear God... lol
P.S. my English is also terrible.
So, works such as http://www.ics.uci.edu/~sjcrane/papers/sjcrane15_readactor.p... (and several others) are attempting to come up with systems that can prevent this type of attack by preventing executable memory from being read in the first place. This is made difficult not only by the fact that even if processors could support such permissions (many generally can't in any efficient fashion), but also due to the fact that many compilers frequently mix together executable code and static data, such as strings. The second paper I linked is about instrumenting LLVM to ensure that it always outputs readable data and code in separate sections.
Having been involved in such research myself, I can confidently respond to the parent's question too by saying that, if anything, a majority of modern compilers freely mix code and data. In addition, there is often data that is directly related to code, such as tables of addresses used in a switch statement, but is never intended to be directly executed. Even if it would work just fine to place such tables in a read-only section, it may make logical sense to the compiler authors to place it in the vicinity of where it is used (that is, in the executable data section).
[0] https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...