<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
[all tangent]<BR>
This indirectly answers one of my questions perhaps, as to the level of avoiding cloning headers.<BR>
<BR>
You have no problem with this level of header cloning:<BR>
<BR>
Uexec.i3<BR>
<*external*><BR>
PROCEDURE waitpid(pid:Utypes.pid_t, status:UNTRACED REF int, int options):int;<BR><BR><BR>
You know -- 1) the need to define pid_t correctly.<BR>
2) The assumption that it is trafficing in int, and not e.g. short or long?<BR>
<BR>
"portable enough"? I think maybe so.<BR>
<BR>
And even this can be "checked" on native builds, but always used "directly".<BR>
<BR>
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.<BR>
<BR>
- Jay<BR><BR>> From: hosking@cs.purdue.edu<BR>> To: jkrell@elego.de<BR>> Date: Mon, 12 Jan 2009 22:42:06 +1100<BR>> CC: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> PS I would love to avoid cloning the headers. waitpid would be <BR>> invocable without any wrapper -- it's up to the client code to <BR>> interpret the status word properly as needs.<BR>> <BR>> <BR>> On 12 Jan 2009, at 12:28, Jay Krell wrote:<BR>> <BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 09/01/12 12:28:31<BR>> ><BR>> > Modified files:<BR>> > cm3/m3-libs/m3core/src/unix/big-endian/: m3makefile<BR>> > cm3/m3-libs/m3core/src/unix/little-endian/: m3makefile<BR>> > cm3/m3-libs/m3core/src/unix/Common/: m3makefile<BR>> > Added files:<BR>> > cm3/m3-libs/m3core/src/unix/big-endian/: Uexec.i3<BR>> > cm3/m3-libs/m3core/src/unix/little-endian/: Uexec.i3<BR>> ><BR>> > Log message:<BR>> > clone more headers to account for non portable waitpid <BR>> > reintroduction; what was wrong with what was here? Aren't several <BR>> > ports wrong e.g. {I386,AMD64}_DARWIN, PPC_LINUX? I guess the point <BR>> > is to stop anyone from using this data at all, so as to not need to <BR>> > return it one way or the other?<BR>> <BR><BR></body>
</html>