Peter N Lewis wrote:
Adriaan van Os wrote:
I now read that Apple has gone completely mad http://lists.apple.com/archives/Xcode-users/2005/Nov/msg00402.html. Bad news.
I agree entirely with their reasoning (the stack should not be executable, it makes far too many exploits possible),
I don't, they have apparently problems with CFM code, so instead of fixing those problems they choose the easy way. Why don't they forbid the execution of *any* code on the Macintosh ? That would be the ultimate safety precaution.
but their solution does indeed sound like madness. Surely it cannot be all that hard to support nested functions without stack based execution?
You can put the trampolining code in a stack-like array (see the last section of http://people.debian.org/~aaronl/Usenix88-lexic.pdf) but that part of memory then still must be made executable. The Darwin kernel forbidding to make any memory executable would be the end of interfacing with CFM code - but you never know what they decide in Cupertino. I will be glad when at some point in the future we all work with free open-source operating systems where the decisions are taken by sane people on sane grounds, after thorough and open discussion. At present, we are entirely dependent on what some empty headed manager in Cupertino or Redmond decides.
Note that trampolines are not needed for nested procedures as such - only when you pass them as actual procedural parameter.
Also note that trampolines are far from optimal, e.g. for the PowerPC the data and execution cache must be flushed. Trampolines are only there for compatibility with C (http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html). A more elegant and efficient solution is given by Niklaus Wirth in his book on compiler architecture [1] by passing the static link pointer along with the address of the nested procedure. I proposed that solution for FPC.
Regards,
Adriaan van Os
[1] Niklaus Wirth, Grundlagen und Techniken des Compilerbaus, Addison Wesley 1996, ISBN 3-89319-931-4 (also translate in English)