No, I'm doing a 32 bit build on a 64bit platform -----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
