[Mono-devel-list] malloc and free on CLI

[Massimiliano Mantione]

On Mon, 2005-07-18 at 11:26 +0200, Paolo Molaro wrote:
> Icalls are completely out of the question
> as an implementation for this.

Happy to hear this!

> The managed C compiler should implement two patterns, both of which
> are required:
> 1) map a function call to a dllimport
> 2) map a function call to corlib/System/ManagedLibc methods

This makes sense, and I would add (maybe it was implied) that case
2 includes any kind of managed code, including any C library that
has been compiled into a managed dll.

Later on you describe a way of using C attributes to specify how
to resolve the two kinds of mapping.
I agree this should be done, but IMHO another way should also be
provided.

Think of the following scenario: a library (say zlib) is compiled
to managed code (so we have zlib.dll).
Another existing C program that we want to compile to managed code
uses zlib (which means its sources include the zlib headers).
Now, the zlib headers do not contain any mapping attribute (and
IMHO they should stay as they are), so we need another way to tell
the C compiler how to map those calls.
I presume the C compiler generates a class with a lot of static
methods, one for each C function.
One easy way to specify the mapping outside of the header files
would be to tell the compiler "all the static methods of these
classes are managed C functions, and they have precedence over
their unmanaged dllimported ones".
Since the C namespace (for linking) is flat, this should work very
well.
An even easier approach would be having a way to tell, in a given
dll, all the managed C functions it contains.
This way, in the above example, it would be enough to tell the
compiler "use zlib.dll"; the compiler should populate the symbol
table with all the C declarations that it can extract from the dll
metadata, and when it later parses the zlib headers, it knows it
must apply the "managed call" mapping style.

I hope I explained the point clearly ;-)

And by the way, I totally agree with Paolo on the issues (risks) of
having two function implementations (one managed and one unmanaged).
This can easily get trickier than expected.
For instance, in the above example, imagine that the program also
depends on another C library (libfoo.so), that for some reason will
not be compiled to managed code.
Suppose that also foo uses zlib (why not?), and suppose that the
program passes zlib "compressed streams" to foo calls...
I think you get the point: if the behavior of zlib.dll and libzlib.so
calls is not *exactly* the same, you'll get all sort of bugs.
By *exactly* the same I in the end mean ABI compatible: structure
layouts, eventual use of static variables... ok, marshalling was
invented to solve these issues, but the above scenario seems messy
anyway to me.

Ciao,
  Massi