| > It's questionable whether people wanted that performance though, at least when it resulted in less security. There's no question about it, the "ANSI C Rationale" makes it very clear what they considered "the spirit of C"[1]: > - Trust the programmer. > - Don't prevent the programmer from doing what needs to be done. > - Keep the language small and simple. > - Provide only one way to do an operation. > - Make it fast, even if it is not guaranteed to be portable. > The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine. > One of the goals of the Committee was to avoid interfering with the ability of translators to generate compact, efficient code. In several cases the Committee has introduced features to improve the possible efficiency of the generated code; for instance, floating point operations may be performed in single-precision if both operands are float rather than double. [1] http://www.lysator.liu.se/c/rat/title.html Quoted section is found here: http://www.lysator.liu.se/c/rat/a.html#1 |