* On 30.10.2011 09:56 PM, Jonathan Wakely wrote: > On 30 October 2011 20:42, Mihai Moldovan wrote: >> * On 30.10.2011 09:24 PM, Jonathan Wakely wrote: >>> On 30 October 2011 19:25, Mihai Moldovan wrote: >>>> As the first paste in http://trac.macports.org/ticket/27237#comment:14 >>>> suggests (extracted from new_allocator.h:98), __p should be permitted to >>>> be a null pointer.. which... well, is clearly not the case here for some >>>> reason. >>> Calling delete on a null pointer is permitted, but passing a null >>> pointer to that allocator's deallocate function is not. Which is it? >> Did you have a look at the paste? new_allocator.h:98 is "{ ::operator >> delete(__p); }" which is the deallocate function, yep. > That's ok to call with a null pointer then, operator delete can be > called with a null pointer. > > From another trac comment: > > Breakpoint 9, std::string::assign (this=0x101777fa8, __str=<value > temporarily unavailable, due to optimizations>) at new_allocator.h:98 > 98 { ::operator delete(__p); } > (gdb) print __p > Cannot access memory at address 0x0 > > > That doesn't look like __p is null to me, I would expect it to print > 0x0 for a null pointer: > > (gdb) print __p > $1 = 0x0 Yeah, delete can be called on a null pointer, but free shouldn't, or am I messing something up? On the other hand, why would free() crash if __p was not null? It may have been previously free'd but... I don't see that happening. Still, something weird is happening here and the GCC build system shouldn't try to use the new stdlibc++, I wonder why and how it tries to in the first place.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
