On 3/12/2013 3:53 PM, Aurélien Aptel wrote:
>>> a) a function can allocate memory that has to be freed
>>
>> At least on Windows, this cannot be done safely, so please don't
>> design the interface based on the assumption this is doable.  If a
>> shared object allocates memory, it should be responsible for freeing
>> it, or provide an API for telling it to free it.
> 
> I'm not sure I understand. You're saying that freeing a pointer
> returned by a library function which explicitly says you have to free
> it yourself is not safe on Windows? That seems strange.

Free using which heap? It's common for different modules in a Windows process to
use entirely different C runtime libraries. On Windows, all inter-module
dependencies are (module, symbol) pairs (written "module!symbol"), not just bare
symbol names as on ELF systems. That is, modA!fun1 calling modB!fun2 can exist
in the same process as a modC!fun1 calling modD!fun2. One module's malloc isn't
necessarily (and often isn't) the same as another module's malloc. It's also
common for Windows programs to allocate memory off private heaps, although
that's discouraged these days for performance reasons.

There's nothing stopping a POSIXish program from using multiple heaps either,
but due to tradition and the way ELF dynamically binds symbols, you're likely to
see most parts of a typical more programs tend to just use the system libc. It's
good practice, though, on both Windows and POSIXish systems, to provide a
function resource-specific (or at least module-specific) deallocation functions.
It's just that if you don't follow this advice under Windows, heap corruption
shoots you in the face.

(Incidentally, one of the challenges of writing Python loadable modules for
Windows is that Python is written with the assumption that all parts of the
program share the same libc, so if foo.pyd isn't linked to precisely the same
version of the C runtime that python27.dll is linked to, things go wrong very
quickly.)

Sometimes Windows library specify that memory is allocated on the "process
heap". The process heap is provided by ntdll.dll and functions more like a
Posixish system's libc heap in that it's shared by all parts of a process; see
HeapAlloc and HeapFree. Likewise, you can't share file descriptors or FILE*
pointers between different modules under Windows, but you *can* share HANDLEs,
since HANDLEs are universal and managed by the kernel.