<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The real world is unsafe.<BR>Safe areas are created by unsafe code, which must be, to a certain extent, bug free, in order to provide as safe as advertised.<BR> <BR> <BR>I don't believe what I added is any more untrusted/unsafe than what was there before.<BR>Well, maybe in a minor way.<BR> <BR> <BR>m3core has "lots" of "external" functions, which are called by "lots" of functions at higher levels..ok, maybe not "lots", but if you look at the m3core/src/unix directories that I have worked on -- cygwin, openbsd, amd64_linux, linux-common -- this is a fairly minimal set of stuff that is being used by preexisting code. A LITTLE bit I added beyond what was there. If you look at all the other directories, you'll find lots more external stuff, most of which is not used within the CM3 codebase (but could be used by folks outside).<BR> <BR> <BR>It is true I may have introduced external where it wasn't previously, but I don't think it matters.<BR>It is prevalent one level down. Moving some of it one level up is ok I believe. <BR> <BR>
<BR>Non-Posix does potentially have a place in .c files.<BR>It depends.<BR>Basically, as I see things, a small amount of #ifdef is ok.<BR>A lot of #ifdef becomes hard to read, and at some point, you split the files into separate files, "no" #ifdefs -- or conceptually each file can be viewed as wrapped in an #ifdef or other platform detection.<BR>You need #ifdef in any C that uses 64 bit integers, for example. Current Microsoft compilers do support "long long" but __int64 supporg goes way back, and __int64 is a better name anyway.<BR>
What is the 128 bit integer type to be called -- "__int128" or "long long long".<BR>
<BR>
<BR>
The names "char", "short", "int", "long", "long long" are mostly just funny mistaken names.<BR>
The right names to provide are explicitly sized, int8, uint8, int16, uint16, int32, uint32, int64, uint64, and pointer sized types such as "size_t" and "diff_t".<BR>
Modula-3 I think is reasonable here, since it's primary integral type is pointer sized, and it has "bits x for ...", though the other types probably ought to be built in and blessed somewhere, not just in the Csupport library section.<BR>
<BR> <BR>
Not sure what "Posix" means, since it might incorporate by-reference ANSI C.<BR>
<BR>
<BR> - Jay<BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
<BR>Date: Sat, 20 Dec 2008 00:09:41 +0000<BR>From: dabenavidesd@yahoo.es<BR>To: m3devel@elegosoft.com<BR>Subject: [M3devel] Rv: Re: serial/Cygwin was Re: [M3commit] FilePosixC.c<BR><BR><BR><BR>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=top>Dear all:<BR>I'm glad that Jay and all the people around are making contributions, so we can claim that as some day there were a good number of supported platforms nowadays we also have.<BR>However I have a question, but its more a suggestion, the modification Tony is referring is not as standard as we would like since the type safety is affected with the change introduced allowing <<SPAN class=EC_current-rev>*</SPAN>EXTERNAL<SPAN class=EC_current-rev>*</SPAN>> (untrusted) functions in the INTERFACE FilePosix, it's an implementation issue of the CM3 (IMHO it should warn) compiler, so we may want to mark as UNSAFE INTERFACE, however doing that I think some clients could not claim any more they are safe so that "fix" is not feasible.<BR>Can you push to a lower level (as in the UNSAFE FilePosix implementation module before committing the change) or make it available in other Interface already available, why do we need that change anyway? Also IMHO we should leave out what is not POSIX (we should not care for WIN64 although I know is needed by the C compiler preprocessor) out of that file.<BR>Although I don't have the formal specification or program, but I can remember libm3 code was specified and mechanically checked with the Extended Static Checker Modula-3 (which is not sound also, that is could be cheated, see http://www.researchchannel.org/prog/displayevent.aspx?rID=2761&fID=345 ), that would be a good reason for keeping as safe as possible and close to historical interfaces and just rework implementations (even if they are not safe) as needed. I know that implementation is not safe but at least having it well enough implemented the ESC/M3 checker and the compiler would tell us the library should work Ok and is safe and (hopefully) without the errors detected by the ESC as we care for the details in the UNSAFE implementation.<BR>There are any special interfaces we should have as "standard" in the lower level runtime (hard enough question I know), can we give some hints/ideas on that?<BR>Thanks in advance<BR><BR><BR><BR>--- El <B>vie, 19/12/08, Jay <I><jay.krell@cornell.edu></I></B> escribió:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px">De: Jay <jay.krell@cornell.edu><BR>Asunto: Re: [M3devel] serial/Cygwin<BR>Para: "m3devel" <m3devel@elegosoft.com>, "Tony" <hosking@cs.purdue.edu><BR>Fecha: viernes, 19 diciembre, 2008 1:25<BR><BR><PRE>> And I'll fix SOLsun/gnu.<BR><BR>I /think/ it is ok now -- changing my "ino_t" to<BR>"m3_ino_t".<BR>I'm still checking though.<BR>And I only checked SOLgnu. I will check SOLsun.<BR> <BR> - Jay<BR> </PRE></BLOCKQUOTE><BR></TD></TR></TBODY></TABLE><BR></body>
</html>