Re: [DotGNU]Hello from pnetC

[Rhys Weatherley]

Gopal V wrote:

> On the other hand , I have been thinking today on how C & C# can interact
> via CSafe .. the __invoke__ stuff can be a significant problem when dealing
> with the IO architecture ....

Since I'll be writing most of the IO architecture for
"unistd", it's "my significant problem". :-)

The "__invoke__" stuff is a pain, deliberately.  I want to
discourage people from calling out to C# in their own
application code - it destroys the portability of the user's
C code.

Integration should be possible, but we don't want to create
a completely new language that people end up getting locked
into.  That way lies Managed C++ Extensions and vendor lock-in.

We have a duty to GNU to stick to standards wherever possible.
A user who writes a C application with cscc should still be
able to compile it with gcc.  The harder we make it to call
out, the more portable their code will be.

Things will be a lot easier once the libc starts falling
into place.  Right now it is impossible to do anything useful
without a C# callout.  This state of affairs won't last long.

> for example how do I catch a I/O exception in C ? (/me guesses we'll build
> the CRT0.dll in C# to handle all that....)

The libc library will probably have a little bit of C# code
in it to handle things like this.  This is actually one of
the reasons why I hate error-reporting via exceptions.  It
can be very difficult to convert the errors into a different
representation without a lot of ugly wrapper code.

> I have been talking on IRC about implementing string.h and the obvious
> question is "should we use String.Equals(String,String)" ? or the default
> model of pointer addition and comparison ?...

"String.Equals" won't work.  A "char *" string in C is a pointer
to a '\0'-terminated array of 8-bit integers.  Zillions of lines
of C code depend upon this behaviour.  A "String" in C# is an
object that contains an array of 16-bit Unicode characters.  They
aren't compatible.

The strXXX and memXXX operations will need to be implemented with
raw pointer operations.  Some CIL assembly speed-ups are possible
in a few cases, but not all.

Cheers,

Rhys.