zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-03 18:13:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source 
(Pascal Massimino)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@289
This commit is contained in:
Julian Seward 2002-05-18 11:09:19 +00:00
parent a3f80dfc46
commit e45ef9f6cc
4 changed files with 56 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
cachegrind/docs/manual.html
View File

@ -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

18
coregrind/docs/manual.html
View File

@ -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

18
docs/manual.html
View File

@ -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

18
memcheck/docs/manual.html
View File

@ -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