[M3commit] CVS Update: cm3

[Jay]

[all tangent]
This indirectly answers one of my questions perhaps, as to the level of avoiding cloning headers.
 
You have no problem with this level of header cloning:
 
Uexec.i3
<*external*>
PROCEDURE waitpid(pid:Utypes.pid_t, status:UNTRACED REF int, int options):int;
You know -- 1) the need to define pid_t correctly.
2) The assumption that it is trafficing in int, and not e.g. short or long?
 
"portable enough"? I think maybe so.
 
And even this can be "checked" on native builds, but always used "directly".
 
There is an argument that even something "like this" would benefit from being wrapped in C where we have very tight control over the Modula-3<->C transition.
 
 - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 22:42:06 +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/dc2e8eb7/attachment-0002.html>