From e45ef9f6cc59b2f0ec605cc808aad3d7d08cca36 Mon Sep 17 00:00:00 2001 From: Julian Seward Date: Sat, 18 May 2002 11:09:19 +0000 Subject: [PATCH] Add clarification of the purpose of the malloc/free mismatch checks (Pascal Massimino) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@289 --- cachegrind/docs/manual.html | 18 ++++++++++++++---- coregrind/docs/manual.html | 18 ++++++++++++++---- docs/manual.html | 18 ++++++++++++++---- memcheck/docs/manual.html | 18 ++++++++++++++---- 4 files changed, 56 insertions(+), 16 deletions(-) diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html index 20fbb36b59..607b55bb76 100644 --- 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.

2.6.4  When a block is freed with an inappropriate deallocation function

-In the following example, a block allocated with new [] +In the following example, a block allocated with new[] has wrongly been deallocated with free: 
   Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 
  • If allocated with malloc, calloc,
     realloc, valloc or
     memalign, you must deallocate with free.
-
  • If allocated with new [], you must deallocate with
-    delete [].
+
  • If allocated with new[], you must deallocate with
+    delete[].
 
  • If allocated with new, you must deallocate with
     delete.
 
@@ -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".  
-
+
    
+Pascal Massimino adds the following clarification:
+delete[] must be called associated with a
+new[] 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 new or
+new[].  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+new/delete
+new[]/delete[].
 
 
 
    2.6.5  Passing system call parameters with inadequate
diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html
index 20fbb36b59..607b55bb76 100644
--- 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.
 
 
    2.6.4  When a block is freed with an inappropriate
 deallocation function
    
-In the following example, a block allocated with new []
+In the following example, a block allocated with new[]
 has wrongly been deallocated with free:
 
       Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 
  • If allocated with malloc, calloc,
     realloc, valloc or
     memalign, you must deallocate with free.
-
  • If allocated with new [], you must deallocate with
-    delete [].
+
  • If allocated with new[], you must deallocate with
+    delete[].
 
  • If allocated with new, you must deallocate with
     delete.
 
@@ -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".  
-
+
    
+Pascal Massimino adds the following clarification:
+delete[] must be called associated with a
+new[] 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 new or
+new[].  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+new/delete
+new[]/delete[].
 
 
 
    2.6.5  Passing system call parameters with inadequate
diff --git a/docs/manual.html b/docs/manual.html
index 20fbb36b59..607b55bb76 100644
--- 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.
 
 
    2.6.4  When a block is freed with an inappropriate
 deallocation function
    
-In the following example, a block allocated with new []
+In the following example, a block allocated with new[]
 has wrongly been deallocated with free:
 
       Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 
  • If allocated with malloc, calloc,
     realloc, valloc or
     memalign, you must deallocate with free.
-
  • If allocated with new [], you must deallocate with
-    delete [].
+
  • If allocated with new[], you must deallocate with
+    delete[].
 
  • If allocated with new, you must deallocate with
     delete.
 
@@ -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".  
-
+
    
+Pascal Massimino adds the following clarification:
+delete[] must be called associated with a
+new[] 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 new or
+new[].  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+new/delete
+new[]/delete[].
 
 
 
    2.6.5  Passing system call parameters with inadequate
diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html
index 20fbb36b59..607b55bb76 100644
--- 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.
 
 
    2.6.4  When a block is freed with an inappropriate
 deallocation function
    
-In the following example, a block allocated with new []
+In the following example, a block allocated with new[]
 has wrongly been deallocated with free:
 
       Mismatched free() / delete / delete []
@@ -831,8 +831,8 @@ how it was allocated.  The deal is:
 
  • If allocated with malloc, calloc,
     realloc, valloc or
     memalign, you must deallocate with free.
-
  • If allocated with new [], you must deallocate with
-    delete [].
+
  • If allocated with new[], you must deallocate with
+    delete[].
 
  • If allocated with new, you must deallocate with
     delete.
 
@@ -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".  
-
+
    
+Pascal Massimino adds the following clarification:
+delete[] must be called associated with a
+new[] 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 new or
+new[].  It rather surprising how compilers [Ed:
+runtime-support libraries?] are robust to mismatch in
+new/delete
+new[]/delete[].
 
 
 
    2.6.5  Passing system call parameters with inadequate
-- 
2.47.3