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