[M3devel] making Uerror "portable"?

[Tony Hosking]

CONST is faster than VAR since the compiler can optimize them.  Why  
would you want VAR?

On 11 Jan 2009, at 19:58, Jay wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090112/334b0e19/attachment-0001.html>