<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
m3core/unix directions<BR>
<BR>
<BR>My intent here is to further reduce platform dependencies and header cloning.<BR>I know there isn't much left, but there is some.<BR>
<BR>
<BR>In particular:<BR> eliminate struct_timespec (done)<BR><BR>
eliminate struct_timeval (partly done, more to do)<BR> implies eliminating select wrapper <BR> implies eliminating gettimeofday wrapper <BR><BR>
eliminate MAX_FDSET <BR>
Though there is a possible bug workaround in m3core, that Interix's header is wrong.<BR><BR>
eliminate time_t (I'd also like to find some way to get 64bit time_t everywhere,<BR> though my research so far says it isn't available)<BR><BR>
eliminate struct_tm <BR>
Mainly used by m3core/src/time.<BR>
As well as fix m3-mail/webcard, m3-mail/postcard which have crashing bugs due to declaring their own form.<BR><BR>
eliminate struct_sockaddr_in <BR><BR>
maybe eliminate struct_sockaddr_un (I know it was requested) <BR><BR>
eliminate all of the Usysdep.i3 files (MAX_FDSET, struct_tm) <BR><BR>
maybe eliminate ioctl/fcntl; there are precious few uses; is the Solaris bug workaround <BR> for them needed? That bug workaround is a good reason to keep the wrappers.<BR><BR>
maybe eliminate stat; there there again there are interesting bug workarounds in<BR> the wrappers, the incorrect headers I had for Darwin/arm <BR>
<BR>
maybe reduce what all m3core/src/unix provides/wraps, leave it to the clients;<BR>
however to the extent that they are just const char* and int, probably ok<BR>
to just leave asis (e.g. open/read/write/close)<BR>
<BR>
<BR>I'm not sure I'll succeed at all of this, but each step I believe has value.<BR>General strategy is to push C up one level. Pass around types<BR> that we have complete control of.<BR>
<BR>
<BR>There is always C below the Posix ports of Modula-3, as well as the Win32/NT port.<BR>It is "just" a matter at where the line is.<BR>
<BR>
<BR>A hypothetical Modula-3 "OS" wouldn't necessarily use any of this C, if it<BR>provided m3core/libm3/tcp directly.<BR>
<BR>
<BR>btw, here's a likely example of the bugs these patterns have caused:<BR>
<BR>
<BR>C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion<BR>C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion<BR>
<BR>
<BR>To mitigate appearance of hypocrisy, I'm willing to do this work on the Win32 header clones also.<BR>Though I think they are a smaller and bigger problem.<BR>Bigger because we have cloned *a lot*.<BR>Smaller because they vary less across the various Win32 architectures.<BR>Similar in size because we use only a small part of them, analogous to what we use for Unix.<BR>
<BR>
<BR>I speculate that stuff like OpenGL and X Windows aren't as problematic because<BR>they are fairly independent of OS/kernel.<BR>It is the "libc as kernel wrapper" where the problems are worse, given the<BR> relatively large number of varieties (Linux, *BSD, NT, Solaris, Darwin).<BR>Though they could still embed e.g. time_t, struct timeval, etc.<BR>
<BR>
<BR>
- Jay<BR> </body>
</html>