<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I still find pushing the system dependencies and cloned headers out of the system very tempting.<BR>
To reduce what it takes to port to other systems, to raise the confidence of the correctness of any port, to keep ports correct in the face of possible underlying change.<BR>
<BR>
I think I'll change the case statements to if/else ladders and the consts to vars, that are actually statically initialized in C. This treatment is reasonable for other constants that remain in the cloned headers, system dependent or otherwise.<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Subject: making Uerror "portable"?<BR>Date: Thu, 8 Jan 2009 06:36:44 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I've been thinking about "fixing" Uerror<BR>to remove the system-dependentness of it.<BR> <BR><BR>I have about given up.<BR> <BR><BR>There are multiple easy options, but they<BR>all have downsides that make me think it<BR>might not be worth it.<BR> <BR><BR>today it looks like:<BR> <BR> <BR>INTERFACE Uerror;<BR>CONST<BR> ENOFILE = 1;<BR> ENOMEM = 2;<BR>END Uerror;<BR> <BR> <BR>The values are intended the correct native values.<BR>There are a fair number of users.<BR>Fewer than 10 probably.<BR>They include switch/case statements, which require<BR>constants.<BR> <BR><BR>The following are some of the possible changes,<BR>that make porting to basically any future system<BR>be a no-op in this area, except for the occasional missing or possibly<BR>equal errnos (if there is a switch in the C code; I ran into this case).<BR> <BR><BR> - Change to VAR and initialize them in portable C code.<BR> disadvantages:<BR> more startup code <BR> possibly startup code runs too late <BR> more writable/written data (readonly data is best) <BR> slower to access <BR> not constant, not switchable, not source quite compatible<BR> You have to change the switch statements to "if ladders" (if/elseif/elseif/elseif).<BR> Compatible with most source, and incompatible source easily fixed.<BR> possible issues around "dynamic linking data" (not explained here, ask?) <BR> However not really a problem. More of a problem only on NT, and easily worked<BR> around just like is done for hand.obj.<BR> <BR><BR> - change to VAR and const static initialize them in portable C "data"<BR> no additional startup code -- guaranteed initialized early enough <BR> no writable/written data<BR> slower to access <BR> not constant, not switchable, not source compatible (same as previous) <BR> same non-issue around dynamic linking of data <BR> <BR><BR> - change to functions GetENOFILE(), GetENOMEM(), etc.<BR> slower to access<BR> definitely no problem dynamic linking <BR> easier to write the C code/data, no matter, the above<BR> are easy enough <BR> not constant, not switchable, not source compatible (similar to previous) <BR> <BR><BR> - "translation"; introduce our own arbitrary values for<BR> any errno the system uses; change Cerrno.GetErrno to have<BR> a switch and translate from the native values to ours.<BR> <BR><BR> This is fully source compatible, dynamic link compatible,<BR> in-between perf wise (slower to GetErrnor, but then constant<BR> and just as comparable/switchable), no initialization cost.<BR> <BR><BR> Question then though what does any raised exception look like?<BR> Do the values get translated back? Or translated to strings?<BR> SetErrno translates back? <BR> <BR> <BR> Translation is at first simple and is unique among portable solutions<BR> in its source compatibility, but I am leary of it. I would<BR> rather a solution that traffics in unmodified native errnos values, but<BR> I don't that is viable with both constness and portability.<BR> <BR> <BR> To a large extent, translation is ok. If you look at SocketPosix.i3, it<BR> uses the errno very briefly to determine the next step to take. I don't think<BR> it ever returns or RAISEs it (or an exception containing it).<BR><BR> But other parts of the system Fmt.Int(errno) and raise that, thus<BR> these become values that move through more of the system and therefore<BR> disagreement with the underlying system might show through.<BR> <BR><BR> There is also question of how to chose "Max". Set it large, like 200?<BR> Set it "correctly"? Probably a better option is to make the cache<BR> that is currently Max-sized be instead small and fixed-size (e.g. 64),<BR> and "search" it quickly instead of "indexing" it very quickly, and always<BR> kick out the least recently used. I also have to check what the<BR> contents actually are, perhaps they are constant-initializable.<BR> <BR> <BR> Thoughts? <BR> <BR><BR> I was somewhat keen to do something here, but have pretty much given up and<BR> will just generate Uerror.i3 for Solaris, NetBSD, FreeBSD, AIX, Irix, HP-UX, etc..<BR> I might still be able to remove the Usignal and Ustat system-dependentness<BR> in m3core/src/unix, but Uerror will probably stand asis (in linux-common,<BR> openbsd-common, cygwin).<BR> <BR> <BR>In particular, I was putting off any more ports till I got the amount of work needed<BR>to port reduced to my satisfaction. I think I'm nearly there.<BR> <BR><BR> - Jay<BR><BR><BR></body>
</html>