C语言对闭包运算的支持

davelv

回复 49# zylthinking


我可以理解成， 这是在夸我吗？

zylthinking

virtualprotect做为公开api， 不可能让它崩溃的。不崩就对了

OwnWaterloo

回复 52# davelv


我不感兴趣仅仅是因为它是一个gcc扩展， 也就是说源代码很可能就没法用别的编译器编译， 产生的代码也许也没法同别的编译器产生的代码交互。
对这个技术本身还是感兴趣的。


诶……  怎么会…… 如果你还对这个感兴趣的话， 要不试试：
1. i386
2. windows开启DEP
3. 下面的代码：

1. 
   
2. int main(void)
   
3. {
   
4.       ((void (*)(void))"\xc3")();
   
5.       return 0;
   
6. }
   

复制代码

应该是会触发DEP的……




如果上面的代码会触发， 但你在1楼帖的代码不会， 那可能是gcc实现方式有变化。
如果上面的代码也不会触发……  我也不知道为什么了………………

zylthinking

为什么一定解释成栈上即时分配可执行代码呢， 这解释本身就有些不自然，应该是编译期生成，至于为什么不能在其他地方用，想想function内的static变量。

zylthinking

为什么一定解释成栈上即时分配可执行代码呢， 这解释本身就有些不自然，应该是编译期生成，至于为什么不能在 ...
zylthinking 发表于 2011-12-05 00:07

靠， 还真是在栈上耍花招了， 看了半天反汇编， 才看明白

starwing83

代码估计还是在text域，栈上面应该是个小thumb（WTL那种），至于为嘛在栈上分配。因为忘了是哪个规定的了，栈上的内存应该是可读可写可执行的。

NalaGinrut

回复 1# davelv


    Gcc扩展是允许你这么干的，甚至可以允许你在C里面实现尾递归。不过这种尝试对C语言来说没有太大的实际意义，也不会有人真的拿C这么用的。

davelv

回复 55# OwnWaterloo

这个在windows下的确会崩，Linux下没有崩。
PE和ELF文件对段的处理方式也不尽相同。

davelv

回复 57# zylthinking

mingw比我在Linux下用的原生gcc行为更怪异，它是在文本段为每一个库函数调用都生成了一小块代码。

tony_ayuan

回复 41# davelv

代码稍微简化了一下。

函数f返回符合声明的函数指针。

我觉得还不是闭包。注释里的代码是等价的。

1. 
   
2. /*
   
3. int n(int y)
   
4. {
   
5.   return y<<1;
   
6. }
   
7. 
   
8. int (*f(void))(int x)
   
9. {
   
10.   return n;
    
11. }
    
12. */
    
13. 
    
14. int (*f(void))(int x)
    
15. {   
    
16.   int n(int y)
    
17.   {   
    
18.     return y<<1;
    
19.   }
    
20.   return n;
    
21. }
    
22. 
    
23. #include <stdio.h>
    
24. 
    
25. int main(void)
    
26. {
    
27.   printf("%d\n",f()(5));
    
28. }
    

复制代码