From 481b5c1a8da44f6459a0b88a3be9e9476c8d8588 Mon Sep 17 00:00:00 2001 From: Jesper Juhl Date: Tue, 8 May 2007 00:31:06 -0700 Subject: [PATCH] --- yaml --- r: 54713 b: refs/heads/master c: 53ab97a1c1536015d4d6d900363ea96fece5ed97 h: refs/heads/master i: 54711: 512ee52909b81d15357613dbc16a1f0aa39f5a5d v: v3 --- [refs] | 2 +- trunk/Documentation/CodingStyle | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/[refs] b/[refs] index 819d4cea083f..4d962829713d 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 4f99ed67cc1cf5302ea18aa042d75641b61a0a1b +refs/heads/master: 53ab97a1c1536015d4d6d900363ea96fece5ed97 diff --git a/trunk/Documentation/CodingStyle b/trunk/Documentation/CodingStyle index e7f5fc6ef20b..afc286775891 100644 --- a/trunk/Documentation/CodingStyle +++ b/trunk/Documentation/CodingStyle @@ -640,7 +640,7 @@ language. There appears to be a common misperception that gcc has a magic "make me faster" speedup option called "inline". While the use of inlines can be -appropriate (for example as a means of replacing macros, see Chapter 11), it +appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory