[Mono-devel-list] Mono.Posix OEE 0.3
jonpryor at vt.edu
Mon Oct 4 22:02:20 EDT 2004
Mono.Posix Over-Engineered Edition 0.3.
OK, I lied. I'm didn't integrate with CVS after 0.2. Instead I kept
hacking on the current code base... So sue me.
Major Changes since 0.2:
- C code uses typedefs for managed/unmanaged mapping.
I should have done this in the first place...
- Wrapper Classes. More below.
- Managed structs have operator==/!= defined
- String_h class removed in a fit of inconsistency as suggested
by Joshua Tauberer (because "String_h" is just too @#% ugly).
Error-related functions are in Errno, signal-related functions
are in Signal. We'll deal with any other imports from
<string.h> on an as-needed basis (on the hopes we won't need
- The "Utils" class, which contained conversion functions
to/from the managed values, is now named PosixConvert.
As a proof-of-concept for my earlier RFC, there is a set of Posix*
wrapper classes, which follow .NET conventions (PascalCasing, exceptions
on errors, etc.). In addition to the earlier PosixStream, we have:
- PosixEnvironment (CurrentDirectory, GetConfigurationValue,
- PosixFile (Open, Create, SetOwner, etc.)
- PosixGroup (GetGroups, GetMembers)
- PosixProcess (Id, ProcessGroupId, SessionId, etc.)
- PosixUser (GetCurrentUser, GetName, GetGroupID,
These are not fully complete wrapper classes, but they should be
illustrative of plausible future design.
Please see the earlier RFC  for how the wrapper classes should be
About the package
It has a makefile. Unpack the archive, and build:
$ tar xzf Mono-Posix-jp-0.3.tar.gz
$ cd Mono.Posix-jp-0.3
This will create a lot of .cs file, Mono.Posix.dll,
libMonoPosixHelper.so, and lots of test programs.
Main.exe is a badly cobbled test program, which calls stat(2) on all
command line arguments, printing out their information, and tries to
write "hello\n" to the file hello.txt using a PosixStream.
mls.exe is a "managed ls" -- it's there to test readdir(3) and co.
lsui.exe "lists user information" -- dumps out the passwd structure for
a user provided as a command-line argument.
lsgi.exe "lists group information" -- dumps out the group structure for
a group provided as a command-line argument.
I wrote this on Fedora Core 2, so if it doesn't compile on your system,
please let me know so I know what portability issues to fix. Thanks to
Charlie Ford for letting me know about problems compiling on Red Hat 9.
These should be corrected.
Remember that Mono.Posix-OEE uses the same names as the current
Mono.Posix. Consequently, you'll have to set LD_LIBRARY_PATH (or
equivalent) to find the newer library, and you'll have to explicitly
link against OOE's Mono.Posix.dll.
About the Implementation
As mentioned previously, functions are placed in classes named
after the header file they appear in. So open(2) is in the Fcntl class.
Furthermore, C typedefs get their own types. This feature is debatable,
and can be changed, but I thought it was cool. Consequently, the C:
typedef unsigned long size_t;
Becomes the C#:
public struct size_t : IComparable, IFormattable...
private ulong value;
This can get rather tedious, so I have a Perl script which generates the
structure declarations, stub-vt.pl. (This could also be a shell script,
or any other language, if that would be preferred. I'm not sure what
the Mono policy regarding code generation is; I haven't heard of such a
The "typedef" classes all support implicit conversions to their
underlying type, but require explicit conversions back. Usage is thus:
size_t a = (size_t) (1 + 2);
size_t b = (size_t) (a + 42);
I also have enough POSIX support in place to fully implement my
Enumerations now get two conversion functions instead of one from
make-map.cs: a ToManagedType, and a FromManagedType. This allows
managed code to get unmanaged values and convert them to the proper
managed equivalent (useful for Error values, as we get the unconverted
value from Marshal.GetLastWin32Error()), as well as the previous code to
convert managed values to their unmanaged equivalent.
All API exports also follow a consistent naming convention
Open Questions (more to follow, I'm sure):
I need some 64-bit OS advice. Is it safe to assume (as I currently do)
that a 64-bit OS will provide the -64 API call? I don't believe this is
actually safe, as open(2) and open64() should do the same thing on
64-bit platforms, so there isn't any need for open64() (except for
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 30389 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041004/d54ff291/attachment.bin
More information about the Mono-devel-list