Branko Cibej wrote:
> Russell Yanofsky wrote:
>> This isn't generally true. The only situation where having two CRTs
>> will lead to heap corruption is if a pointer malloc()ed in one DLL
>> is free()d in another. Any DLL interface that is meant to be
>> portable to different compilers (i.e. Visual C++, Borland,
>> Metrowerks, Cygwin, Visual Basic) won't pass pointers back and forth
>> this way. I'd be surprised if apr-iconv did this.
>>
> It does, actually.
Oh. What about the other apache libaries and the berkeley library? Do they
also require their callers to use malloc or free?
>> Doesn't apache code use its own memory management instead of malloc
>> and free?
>>
>>
> Yes, but APR's memory management is based on malloc and free in the
> end.
>
> That said, I don't think it would be very hard to change APR to use
> native Win32 functions (due to the nature of APR's pool, VirtualAlloc
> would probably be best), nor teach apr-iconv to stop using malloc and
> shift entirely to pools.
I think the exact opposite of what you said here is true. :)
It's perfectly ok for APR's memory management to be implemented in terms of
malloc and free because all calls to those functions for APR-managed memory
occur within a single DLL and are forwarded to a single CRT (whichever CRT
the DLL was linked against). The only time there is a problem is when you
malloc blocks of memory with one CRT and free them with another.
Also, I think it could take a lot of work to wean apr-iconv off of malloc
and free. To fix this problem, you have to change the libary's interface as
well as its implementation. Specifically, you'd have to change all callers
to not call free() on pointers malloc()ed by the library and to not expect
the library to call free() on pointers passed into it.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 3 09:04:27 2003