Add clarification of the purpose of the malloc/free mismatch checks

(Pascal Massimino)

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@289

diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html
index 20fbb36b594bea57edc24257fd7c4cfc1b97c427..607b55bb7687ea82f675c9daae19e465755fef6e 100644 (file)
--- a/cachegrind/docs/manual.html
+++ b/cachegrind/docs/manual.html
@@ -808,7 +808,7 @@ be told that -- making duplicate frees of the same block easy to spot.
 
 <h4>2.6.4&nbsp; When a block is freed with an inappropriate
 deallocation function</h4>
-In the following example, a block allocated with <code>new []</code>
+In the following example, a block allocated with <code>new[]</code>
 has wrongly been deallocated with <code>free</code>:
 <pre>
   Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 <li>If allocated with <code>malloc</code>, <code>calloc</code>,
     <code>realloc</code>, <code>valloc</code> or
     <code>memalign</code>, you must deallocate with <code>free</code>.
-<li>If allocated with <code>new []</code>, you must deallocate with
-    <code>delete []</code>.
+<li>If allocated with <code>new[]</code>, you must deallocate with
+    <code>delete[]</code>.
 <li>If allocated with <code>new</code>, you must deallocate with
     <code>delete</code>.
 </ul>
@@ -841,7 +841,17 @@ do muddle these up, and it all seems to work ok, but the same program
 may then crash on a different platform, Solaris for example.  So it's
 best to fix it properly.  According to the KDE folks "it's amazing how
 many C++ programmers don't know this".  
-
+<p>
+Pascal Massimino adds the following clarification:
+<code>delete[]</code> must be called associated with a
+<code>new[]</code> because the compiler stores the size of the array
+and the pointer-to-member to the destructor of the array's content
+just before the pointer actually returned.  This implies a
+variable-sized overhead in what's returned by <code>new</code> or
+<code>new[]</code>.  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+<code>new</code>/<code>delete</code>
+<code>new[]</code>/<code>delete[]</code>.
 
 
 <h4>2.6.5&nbsp; Passing system call parameters with inadequate

diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html
index 20fbb36b594bea57edc24257fd7c4cfc1b97c427..607b55bb7687ea82f675c9daae19e465755fef6e 100644 (file)
--- a/coregrind/docs/manual.html
+++ b/coregrind/docs/manual.html
@@ -808,7 +808,7 @@ be told that -- making duplicate frees of the same block easy to spot.
 
 <h4>2.6.4&nbsp; When a block is freed with an inappropriate
 deallocation function</h4>
-In the following example, a block allocated with <code>new []</code>
+In the following example, a block allocated with <code>new[]</code>
 has wrongly been deallocated with <code>free</code>:
 <pre>
   Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 <li>If allocated with <code>malloc</code>, <code>calloc</code>,
     <code>realloc</code>, <code>valloc</code> or
     <code>memalign</code>, you must deallocate with <code>free</code>.
-<li>If allocated with <code>new []</code>, you must deallocate with
-    <code>delete []</code>.
+<li>If allocated with <code>new[]</code>, you must deallocate with
+    <code>delete[]</code>.
 <li>If allocated with <code>new</code>, you must deallocate with
     <code>delete</code>.
 </ul>
@@ -841,7 +841,17 @@ do muddle these up, and it all seems to work ok, but the same program
 may then crash on a different platform, Solaris for example.  So it's
 best to fix it properly.  According to the KDE folks "it's amazing how
 many C++ programmers don't know this".  
-
+<p>
+Pascal Massimino adds the following clarification:
+<code>delete[]</code> must be called associated with a
+<code>new[]</code> because the compiler stores the size of the array
+and the pointer-to-member to the destructor of the array's content
+just before the pointer actually returned.  This implies a
+variable-sized overhead in what's returned by <code>new</code> or
+<code>new[]</code>.  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+<code>new</code>/<code>delete</code>
+<code>new[]</code>/<code>delete[]</code>.
 
 
 <h4>2.6.5&nbsp; Passing system call parameters with inadequate

diff --git a/docs/manual.html b/docs/manual.html
index 20fbb36b594bea57edc24257fd7c4cfc1b97c427..607b55bb7687ea82f675c9daae19e465755fef6e 100644 (file)
--- a/docs/manual.html
+++ b/docs/manual.html
@@ -808,7 +808,7 @@ be told that -- making duplicate frees of the same block easy to spot.
 
 <h4>2.6.4&nbsp; When a block is freed with an inappropriate
 deallocation function</h4>
-In the following example, a block allocated with <code>new []</code>
+In the following example, a block allocated with <code>new[]</code>
 has wrongly been deallocated with <code>free</code>:
 <pre>
   Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 <li>If allocated with <code>malloc</code>, <code>calloc</code>,
     <code>realloc</code>, <code>valloc</code> or
     <code>memalign</code>, you must deallocate with <code>free</code>.
-<li>If allocated with <code>new []</code>, you must deallocate with
-    <code>delete []</code>.
+<li>If allocated with <code>new[]</code>, you must deallocate with
+    <code>delete[]</code>.
 <li>If allocated with <code>new</code>, you must deallocate with
     <code>delete</code>.
 </ul>
@@ -841,7 +841,17 @@ do muddle these up, and it all seems to work ok, but the same program
 may then crash on a different platform, Solaris for example.  So it's
 best to fix it properly.  According to the KDE folks "it's amazing how
 many C++ programmers don't know this".  
-
+<p>
+Pascal Massimino adds the following clarification:
+<code>delete[]</code> must be called associated with a
+<code>new[]</code> because the compiler stores the size of the array
+and the pointer-to-member to the destructor of the array's content
+just before the pointer actually returned.  This implies a
+variable-sized overhead in what's returned by <code>new</code> or
+<code>new[]</code>.  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+<code>new</code>/<code>delete</code>
+<code>new[]</code>/<code>delete[]</code>.
 
 
 <h4>2.6.5&nbsp; Passing system call parameters with inadequate

diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html
index 20fbb36b594bea57edc24257fd7c4cfc1b97c427..607b55bb7687ea82f675c9daae19e465755fef6e 100644 (file)
--- a/memcheck/docs/manual.html
+++ b/memcheck/docs/manual.html
@@ -808,7 +808,7 @@ be told that -- making duplicate frees of the same block easy to spot.
 
 <h4>2.6.4&nbsp; When a block is freed with an inappropriate
 deallocation function</h4>
-In the following example, a block allocated with <code>new []</code>
+In the following example, a block allocated with <code>new[]</code>
 has wrongly been deallocated with <code>free</code>:
 <pre>
   Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 <li>If allocated with <code>malloc</code>, <code>calloc</code>,
     <code>realloc</code>, <code>valloc</code> or
     <code>memalign</code>, you must deallocate with <code>free</code>.
-<li>If allocated with <code>new []</code>, you must deallocate with
-    <code>delete []</code>.
+<li>If allocated with <code>new[]</code>, you must deallocate with
+    <code>delete[]</code>.
 <li>If allocated with <code>new</code>, you must deallocate with
     <code>delete</code>.
 </ul>
@@ -841,7 +841,17 @@ do muddle these up, and it all seems to work ok, but the same program
 may then crash on a different platform, Solaris for example.  So it's
 best to fix it properly.  According to the KDE folks "it's amazing how
 many C++ programmers don't know this".  
-
+<p>
+Pascal Massimino adds the following clarification:
+<code>delete[]</code> must be called associated with a
+<code>new[]</code> because the compiler stores the size of the array
+and the pointer-to-member to the destructor of the array's content
+just before the pointer actually returned.  This implies a
+variable-sized overhead in what's returned by <code>new</code> or
+<code>new[]</code>.  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+<code>new</code>/<code>delete</code>
+<code>new[]</code>/<code>delete[]</code>.
 
 
 <h4>2.6.5&nbsp; Passing system call parameters with inadequate