<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Tony, Well, it is a matter of degree, but I really dislike the duplication<BR>
and I believe the portability is plenty attainable. It also didn't compile<BR>
for me on Cygwin, I did a bit more research and fixed that.<BR>
It is ok now for SOLgnu? I do have a SOLgnu/sun machine but didn't rebuild there yet.<BR>
L_SET is not portable.<BR>
<BR>
- Jay<BR><BR>> From: hosking@cs.purdue.edu<BR>> To: jkrell@elego.de<BR>> Date: Wed, 17 Dec 2008 06:33:27 +1100<BR>> CC: m3devel@elegosoft.com; m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> This new file FilePosixC.c does not build on my SOLgnu Tinderbox <BR>> setup, so the regressions failed last night.<BR>> <BR>> Jay, this is precisely the reason that we don't want to have C-coded <BR>> files in the Modula-3 code-base -- C might proclaim its portability <BR>> but that portability is a lie. Why do we need this when the old pure <BR>> Modula-3 setup worked just fine! I know it meant some amount of <BR>> duplication, but that duplication was needed because of differences in <BR>> API specs on different platforms. I am not averse to having <BR>> *portable* C code, but in this case I think it is too low-level to be <BR>> properly portable. Perhaps better to keep it in Modula-3.<BR>> <BR>> On 15 Dec 2008, at 18:33, Jay Krell wrote:<BR>> <BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 08/12/15 18:33:17<BR>> ><BR>> > Modified files:<BR>> > cm3/m3-libs/libm3/src/os/POSIX/: FilePosix.i3 FilePosix.m3<BR>> > m3makefile<BR>> > Added files:<BR>> > cm3/m3-libs/libm3/src/os/POSIX/: FilePosixC.c<BR>> ><BR>> > Log message:<BR>> > Remove the need to untangle the #ifdefs around struct flock.<BR>> <BR><BR></body>
</html>