Re: [DotGNU]Questions about pnet C

[Rhys Weatherley]

Peter Minten wrote:

> 1) Can all existing C code not depending on other libraries than the standard 
> C
> baselib be compiled?

That's the plan.  Full ANSI/ISO C compatibility.

> 2) How can pnet C code call other pnet C code that is not being compiled 
> (libs)?

In C, whenever the compiler encounters an undefined function,
it puts an external reference into the object file.  This
reference is fixed up at link time once the library becomes
available.  The pnet C compiler and linker work the same way.

It isn't necessary to provide "-l" options when compiling
source, as it is with C#.  The one exception is when C code
is calling out to C#, but that's mostly restricted to the
libc implementation.  Application programs should rarely
need to worry about it.

> 3) Can pnet C code call non-pnet C code (aka P/Invoking)?

You can declare functions like this in a .c file:

int foo(char *x, int y) __attribute__((pinvoke("bar.so")));

This will output the necessary PInvoke stub logic.

> IF (ANSWER 3 == TRUE)
> 
> 4) Can all exising C code be compiled by P/Invoking the libraries or by
> compiling the libraries into IL? For example: can I compile GLib and GTK+ to 
> IL
> with pnet C?
> 
> ENDIF

PInvoke is a tempermental beast at the best of times.  It would
be possible to PInvoke out to Gtk+, but you'd need to be careful
of struct layout and the like.  The pnet C compiler does not use
the same struct layout conventions as the underlying native system.

In theory, GLib and Gtk+ could be compiled to IL.  Figuring out
how to implement gdk in the IL environment may be an interesting
diversion for some masochistic soul ( :-) ).

> 5) How can C# code call library functions programmed in pnet C? Example: say I
> have compiled all of GNOME to IL and want to use some of the functionality in
> the GNOME libs.

I haven't quite figured out how to export C to C# yet.  C# does
not have any way to refer to fields and methods in the global space.

> 6) Can pnet C code call non-pnet C code without using the pesky __INVOKE__
> convention.

That "pesky" convention is necessary or massive numbers of shift/reduce
and reduce/reduce conflicts are introduced into the C grammar.  The
syntax of C and C# method calls are fundamentally incompatible.

> Perhaps by using a GTK like method call (system_console_writeline
> (char * string))? This is very important for webservices in C since they
> otherwise can't access methods in a class (and all C# methods are in a class)
> and thus miss out on a lot of functionality.

I'm thinking about it, but need to find the right style which doesn't
end up turning C into C#, and destroying all reasons for having C.

How about this instead: we write a program which takes a C#
assembly in, and spits out .h files to access the functionality
of the assembly from C.  The pesky "__invoke__" conventions are
wrapped up inside C macros so that the programmer gets an
interface similar to your "system_console_writeline" example.

> IF (ANSWER 6 == TRUE)
> 
> 7) Can you pass a String object to a method expecting a char *?
> 
> 8) Can you pass a char[] object to a method expecting a char *?
> 
> ENDIF

There is no automatic conversion of arguments unless you use PInvoke.
This is fundamental to the design of IL, not pnet C.

Cheers,

Rhys.