Linux内核代码使用“语句表达式”和typeof扩展,这使得它只能在gcc下编译。
我想得越多,它就越没有意义。
它违背了可移植性和标准C的目的(现在linux内核代码需要一个支持gcc扩展的特定编译器)。
这是一个糟糕的设计选择,还是有特定的原因让linux内核代码专用于gcc?
编辑:当我说它破坏了可移植性时,我在不同的上下文中使用了它。我在想,通过遵循标准C,它将被任何支持标准C的编译器所接受(这正是创建标准的目的--统一C的所有不同方言),因此更具可移植性。当然,由于gcc如此受欢迎,而gcc又支持千千万万的架构,所以这条线几乎没有意义。我只是问不符合标准C的背后是否有特定的理由。
发布于 2011-11-16 05:43:12
为什么Linux内核开发人员会担心他们的代码在Microsoft Visual Studio编译器或IBM xlC编译器上工作?
当您编写内核时,您需要非常精确地控制比在用户空间中(通常)要多得多的东西,比如确切的内存布局。这样的控制在C标准中并没有真正考虑到(例如,作为实现定义的特征),所以要么需要一些扩展,要么你需要依赖于编译器的怪癖。
坚持使用一个特定的编译器,利用它的扩展,是一个理性的决定。代码不需要跨编译器移植-它需要在不同的硬件平台上高效和可移植。
发布于 2011-11-16 05:59:30
这里有一些关于使用的特定扩展的很好的背景知识。这篇文章并不是从“为什么?”的角度写的,但它应该会给你一些关于选择这种方法的原因的良好背景:
发布于 2011-11-16 05:40:52
Linux内核代码是一个复杂的软件。gcc为他们提供的设施越多,他们就会越高兴。
他们为什么要关心可移植性呢?实际上,gcc在每种硬件配置下都会编译代码,并为它们提供了良好的功能。为什么他们会关心Linux能不能用其他编译器编译?
今天,可移植代码对我们来说是一个如此常见的概念,以至于我们相信它应该无处不在。但事实并非如此。例如,如果编译器为C语言提供了实时扩展,NASA就会使用它,而不关心可移植性。重要的一点是,这些特性太好了,不能为了一个从未使用过的可移植性而牺牲(我的意思是,谁会用MS Visual Studio编译内核呢?)
https://stackoverflow.com/questions/8143417
复制相似问题