<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
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></body>
</html>