Nicole Willson wrote:
No, I'm doing a 32 bit build on a 64bit platform
Okay, so PTRDIFF_MAX is 0x7fffffff and SIZE_MAX, the size of the
largest object, is 0xffffffffU (i.e., 4GB). But in that case I
don't understand how you could have changed the test to allocate
FFFFFFFFFFFFFFFF bytes.
Martin
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 12:05 PM
To: [email protected]
Subject: Re: problem in temp_buffer
Nicole Willson wrote:
Ok, when I changed the test to allocate a significantly larger chunk
of memory (18,446,744,073,709,551,615, the equivalent of
FFFFFFFFFFFFFFFF (8bytes)), it finally failed to allocate and returned
a 0 as expected.
So the question becomes, is the value of _RWSTD_PTRDIFF_MAX incorrect
for this platform, or is it just that there is another problem that
gets covered up by having the memory so large?
I'm not sure I see the relevance of PTRDIFF_MAX but the macro should
expand to the largest value representable in an object of type
ptrdiff_t, which is a signed integer type capable of representing the
difference between any two pointers. It will usually be the same as
LONG_MAX, i.e., 0x7fffffff on 32-bit platforms and 0x7fffffffffffffff on
64-bit platforms.
Btw., if you are doing a 64-bit build the addresses below (in the gdb
output) don't look quite correct.
Martin
Nicole
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 27, 2006 11:50 AM
To: [email protected]
Subject: Re: problem in temp_buffer
Nicole Willson wrote:
The problem is simply that the address for last is:
(gdb) print last
$5 = (Header *) 0x77f00008
And the address for ptr (after malloc) is:
(gdb) print ptr
$4 = (void *) 0x77e00d30
Since ptr is
(gdb) print block_size
$1 = 2147483680
The end of the block pointed to by ptr is 0xf7e00d50 - you will note
that last is inside of ptr's block of memory now. Then when memset is
called on ptr setting everything to -1, last's information is
obliterated.
My question now is:
Since last is in the midst of the block allocated to ptr, shouldn't
that allocation have failed?
The allocation should fail if the size of the requested block (nbytes)
is greater than malloc() can find. If it fails, the returned pointer
will be 0. Otherwise the allocated block must not overlap with any
other previously allocated (and not yet deallocated) block. From what
you said it sounds like last might be pointing to an already
deallocated block of memory (which should not happen). If that's
what's happening you'll need to figure out why :)
Martin
