stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: problem in temp_buffer
Date Fri, 28 Jul 2006 18:04:44 GMT
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