Messages in this thread |  | | From | Jonathan George <> | Subject | RE: Patch to remove undefined C code | Date | Mon, 16 Oct 2000 16:48:18 -0400 |
| |
-----Original Message----- From: Ben Pfaff [mailto:pfaffben@msu.edu] >Jonathan George <Jonathan.George@trcinc.com> writes: > >> This patch has many bogus corrections where new variables were created, but >> the order of evaluation is already unambiguous. >> >> For example each comma separated clause in an expression is guaranteed to be >> completely evaluated before the next comma separated clause Including >> Assignments. > >No, that is not true in general. When the comma in question is >the comma operator, it is true. But when the comma separates >arguments to a function, it is not: the order of evaluation of >function arguments is implementation dependent. See C89 section >6.3.2.2 "Function calls": > > $ The order of evaluation of the function designator, the > $ arguments, and subexpressions within the arguments is > $ unspecified, ... >--
I sit surprised and corrected. With every version of every C compiler on every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using Manx C to E10000 using Kai C++) the behavior has been the same for parameter lists as for the comma operator in this respect. Does this imply that even the evaluation of a function pointer is itself undefined in terms of ordering?
>"Premature optimization is the root of all evil." >--D. E. Knuth, "Structured Programming with go to Statements"
Absolutely true.
However, optimization of well tested, and algorithmically validated kernel code in a time critical section does not constitute premature optimization as I'm sure Donald would agree.
I would be really interested to see how well the kernel compiler does at optimizing out all of these new tmp variables in terms of the resulting register utilization and performance. At least an assembler code size comparison is in order for each of these individual cases.
That is my only real concern (other than all of that syntactically ambiguous code I have written over the last 15 years ;-) is that critical performance not be compromised in the kernel.
--Jonathan-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |