Re: Building GCC 4.6.x on Mac OS X

[Mihai Moldovan <ionic at ionic dot de>]

* 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