stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicole Willson" <>
Subject RE: problem in temp_buffer
Date Fri, 28 Jul 2006 19:09:07 GMT
No, I'm doing a 32 bit build on a 64bit platform 

-----Original Message-----
From: Martin Sebor [] 
Sent: Friday, July 28, 2006 12:05 PM
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.


> Nicole
> -----Original Message-----
> From: Martin Sebor []
> Sent: Thursday, July 27, 2006 11:50 AM
> To:
> 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 
>>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

View raw message