来自：Jian Lin

Jian Lin — Mon, 11 Jan 2010 11:02:42 +0000

@iLRainyday 谢谢指正。查了一下ISO C99，在6.4.4.4节Character constants定义了。我已更正。

来自：iLRainyday

iLRainyday — Mon, 11 Jan 2010 06:16:45 +0000

@根据标准的规定，在C的算术类型提升时，字符常量'a'自动提升为整型，故结果是4（对于32位机器）
---------
这里没有自动提升，无L前缀的character constants的类型本来就是int。这个问题在C FAQ中专门有讲述。

来自：C和C++处理register关键字的一处差异 | 林健的BLOG

C和C++处理register关键字的一处差异 | 林健的BLOG — Sun, 19 Apr 2009 15:08:06 +0000

[...] | 1次阅读　　C++并不是完全兼容C语言的，上次提到的sizeof('a')等于几的问题就是一例。今天我在编码时又无意中发现了一处不同： [...]

来自：编译器与标准——严格还是智能？ | 林健的BLOG

编译器与标准——严格还是智能？ | 林健的BLOG — Sat, 21 Mar 2009 06:25:51 +0000

[...] 　　标准定义的语法在任何编译器下都应该有相同、无歧义的语义。尽管其内部实现可能不同，或是依赖于具体的机器架构，但在标准中总有明确的说明。而标准中也存在大量未定义的语义，这通常是为了让编译器作者放开限制，做更高效、更简单的实现。这类语法在不同的编译器或不同的运行环境下可能产生不同的结果，经典的例子就是n=m+++m++这种副作用语句的叠加，再如L’abcd’表示什么的问题。　　工程中通常应该严格禁用标准未定义的语法，因为机器架构、编译器种类和版本、优化选项、运行时环境等的变化都有可能对程序的运行结果产生不可预知的影响。但有些时候标准未定义的的语法也是有用的，比如为了学习理解编译器的原理和优化算法。另外在一些技巧性游戏，如Quine，以及IOCCC、Time Limit Exceeded这样的hack竞赛中，使用未定义语法的捷径也是未尝不可的。　　而编译器扩展的语法和库则是一类相对有用的工具。不同于标准未定义的内容，编译器所做的扩展也是有严格定义的，不会产生不可预知的结果。在对代码的迁移性要求不高的场合直接使用并无大碍。如果对代码的迁移性有要求，那就如上文所述使用条件编译来限制其作用范围。毕竟编译器所做的扩展是为了弥补标准库的不足，方便开发者。如果对代码将来的使用范围有明显的预知，就需要权衡是否使用编译器的扩展特性。不过就连Linux内核的代码都在使用gcc的扩展语法。　　在C/C++语言教学中，强调标准是十分必要的。然而市面上的C/C++教材鱼目混珠：那天在师兄的桌上看到的一本国内某知名高校出版的C++教材上，Hello World程序竟有3处明显的问题，不用试验就知道在VS2008或gcc下编译有两处是Error，一处至少是Warning（据说在VC6下可以编译通过）。一些高校计算机教学中普遍使用历史遗留的、非标准的编译器也成为滋生不良编程习惯、阻碍标准推广的源泉。究其原因，某些教师的惰性是一方面，而相关资格考试与现行标准、业界规范的严重脱节也成为应试教育体制下技术标准难以为师生重视的重要因素。正面的例子又如何呢？北理工计算机学院有一门程序设计实践与方法的本科课程，这门课的重心本是算法与编程技巧的训练，但由于它使用了基于gcc的Online Judge机制和像ACM-ICPC一样严格、众多的测试用例，使得学生对代码的标准与严格、算法的正确与高效、条件的完全覆盖必须做仔细的考量。我自己上过这门课，也做过这门课的助教，两种角色的体验让我深知师生各自的抱怨与苦衷。错误究竟在谁？我想不在于这门课的教师和学生，而在于这门课之外的计算机教育氛围。改变这个氛围并不可以一蹴而就，但至少有两点是可以尽己所能的：主观方面，建立标准意识，培养良好的编程习惯；客观方面，使用实现了符合现行标准的编译器。尽管这对计算机教学的整体环境影响甚微，但起码对未来从事计算机方面的工作来说是有益的——实际工程对标准的要求非同儿戏。相关文章sizeof的一些牛角尖问题小bug引起的C程序32位-64位移植问题使用C++实现的Java语言子集词法、语法、语义分析器随机数不随机——一个有趣的错误分清程序“所在路径”和“执行路径” [...]

评论：sizeof的一些牛角尖问题

来自：Jian Lin

来自：iLRainyday

来自：C和C++处理register关键字的一处差异 | 林健的BLOG

来自：编译器与标准——严格还是智能？ | 林健的BLOG