[M3commit] CVS Update: cm3

[Jay]

uh oh.I sense a possible big vocabulary difference.
There are, indeed, two ways of cloning headers.
One way is with super tight fidelity.Declaring the types in Modula-3 to match exactly what it is in the .h files..h files that you don't write yourself, that vary from system to system,and may be full of #ifdefs and hard to read (but sure, preprocess them).This is what I don't like.It is tedious, error prone, dangerous.This is historically what was done.
 
The alternative is, well, also cloning headers.You write your own.But you don't put any #ifdefs in them.You make them easy to read.They are the same for Solaris, Linux, little endian, big endian (no bit fields), etc.
The ones you write yourself, you write in both Modula-3 and C.You have your Modula-3 code call your C code, and then your C calls "the OS", viaits headers, that you no longer have to read and clone.
This is what I have been doing.
 
In fact, maybe the ones you write yourself you write in xml or some otherconstrained language/schema, and write a tool to spit out Modula .i3 and C .h files.
 
We are on the same page, right?
Bad to clone /usr/include.
Ok to clone stuff you write yourself.
 
 - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:41:56 +1100> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > PS I would love to avoid cloning the headers. waitpid would be > invocable without any wrapper -- it's up to the client code to > interpret the status word properly as needs.> > > On 12 Jan 2009, at 12:28, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 09/01/12 12:28:31> >> > Modified files:> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3> >> > Log message:> > clone more headers to account for non portable waitpid > > reintroduction; what was wrong with what was here? Aren't several > > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point > > is to stop anyone from using this data at all, so as to not need to > > return it one way or the other?> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090112/92301906/attachment-0002.html>