[Mono-devel-list] Mono.Posix Structuring

Jonathan Pryor jonpryor at vt.edu
Thu Sep 23 21:14:48 EDT 2004

Earlier (on IRC) I had brought up the "problem" of supporting the 64-bit
Extended APIs.  For example, there's stat(2) and stat64().  The extended
APIs are primarily useful for 32-bit platforms that support files larger
than 2^31 bytes.

There are (at least) two ways this could be handled:

	1.  Expose both sets from Mono.Posix.
	2.  Expose an intermediate wrapper from Mono.Posix.

(1) increases complexity, as developers won't know which set to use. 
Miguel had suggested (2), which seems very reasonable.

This raises two questions/ideas:

Q1.  Implementation: to #ifdef, or not to #ifdef, that is the question.

That is, we can either use conditional compilation:

	// ftruncate(2)
	Mono_Posix_ftruncate (gint32 fd, gint64 length)
		return ftruncate64 (fd, length);
		if (length > MAX_INT) {
			errno = EOVERFLOW;
			return -1;
		return ftruncate (fd, (off_t) length);

	// repeat for lots of other functions

Alternatively, we can place the 32-bit and the 64-bit version into
separate files, and only build the correct file.

I'd prefer the first approach, but I'm open to opinions and suggestions.

Q2: Function organization.

Earlier[1] it was suggested that not all methods should go into
Syscall.cs, as not all functions are system calls.

I would suggest organizing the classes by header file, after removing
the ".h" from the standard header file name.  Thus:

	public static class Fcntl
		public static extern int fcntl (int fd, int cmd, long arg);
		public static extern int fcntl (int fd, int cmd, ref flock lock);
		public static extern int open (string pathname, int flags);
		public static extern int open (string pathname, int flags, int mode);
		public static extern int creat (string pathname, int mode);
		// ...

	// Similar for Unistd, Ulimit, etc.

This would prevent lots of different methods from being presented in the
same class, assuming that IEEE did their job and kept similar functions
together when they standardized the header files.

Comments? Suggestions?


 - Jon

More information about the Mono-devel-list mailing list