C语言全局变量那些事儿

着实前面几个例子只是开胃小菜罢了，真正的大坑终于呈现了！并且这次编译器既没报错也没告诫，但我们确实眼睁睁地看到作为main()中强标记的b被改写了，并且一旁的c也“躺枪”了。眼尖的读者发明，这次foo.c是作为动态链接库运行时加载的，当t1第一次挪用t2时，libfoo.so还未加载，一旦挪用了foo函数，b立马中弹，并且c的地点居然还相邻着b，这使得c一同中弹了。不外笔者有些无法表明这种举动的缘故起因，有种说法是强标记的全局变量在数据段中是持续漫衍的（响应地弱标记暂存在.bss段可能标记内外），或者可以上报GNU的编译器开拓小组。

其它笔者实行过将t1.c中的b和c界说前面加上const限制词，编译器如故默认通过，但措施在main()中第一次挪用foo()时触发了Segment fault非常导致奔溃，在foo.c里行使指针改写它也一样。揣度这是GCC对const常量地址地点启用了相同操纵体系写掩护机制，但我无法确定早期版本的GCC是否会让这个const常量被改写而措施不会奔溃。

至于volatile要害词之于全局变量，自测好像没有影响。

怎么样？看了最后一个例子是否有点“不明觉厉”呢？C说话在你心目中是否照旧当初谁人“纯洁”、“干净”、“举动同等”的女人呢？大概趁着你不留意的时辰她会偷偷给你戴顶绿帽，这统统都是通过全局变量，出格在动态链接的情形下，就算所有界说成强标记如故无法为编译器所察觉。而一些IT界“可怕分子”也常常将恶意代码包装玉成局变量注入到root权限下存在裂痕的操纵序列中，就像闻名的栈溢出进攻那样。某一天当你傻傻地看着一个措施呈现未界说的举动却无法定位缘故起因的时辰，请不要健忘Richie大爷那来自地府之下最深沉的“问候”~

或者有些人会掉包观念，把这统统归罪于编译器和链接器身上，以为这同说话无关，但我要提示你，正是编译/链接器的举动支撑了整个说话的语法和语义。你可以反过来思索一下为何C的胞弟C++推出“定名空间(namespace)”的观念，可能你可以行使其余高级说话，对付重界说的全局变量是否能通过编译这一关。

以是请时候服膺，C是一门很可怕的说话！

P.S.题外话写在最后。我有时挑起说话之争，只是就事论事地去“黑(hack)”一门说话罢了，并且要黑就要黑得有理有力有条理，还要带点娱乐精力。着实黑一门说话并非什么尖端伟大的技能，小我私人认为最少要做到两点：

• 亲身下手写测试措施。下手写测试措施是开拓职员必备的基本手艺，只有现成的代码才气让民气服口服，那些只会逗留在口头上的争论只能算作cheap hack。

• 测试措施不能依靠于不成熟的代码。软件开拓99%以上的bug都是基于不及格(substandard)开拓职员导致，这并不能怪罪于说话以及编译器自己。行使诸如#define TRUE FALSE可能#define NULL 1之类的trick来黑C说话只能证明此人很有娱乐精力而不是真正的”hack value”，拿老北京梨园行当里的一句话——“那是下三滥的玩意儿”。

（全文完）

文章来历：http://coolshell.cn/articles/10115.html

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!