[M3devel] making Uerror "portable"?

[Tony Hosking]

On 12 Jan 2009, at 12:09, Jay wrote:

>   Understood.
>   So I can remove Uerror's system-dependentness.
>
>
>   in place of
>   CONST EFOO =1, EBAR = 2;
>
>   I want:
>
>   <*EXTERNAL*> (*const*) VAR EFOO, EBAR:int;

This is gross.  Again, if they are constants in C they should be  
constants in Modula-3.   To reiterate: I think your contortions to  
eliminate C-header-file cloning are distorting the Modula-3 code in  
ways that make it much less transparent.  Can we please revert some of  
these bad design decisions?

>   UerrorC.c:
>   #include <errno.h>
>   enum { eEFOO = EFOO, eEBAR = EBAR };
>   const Max = sizeof(union { char a[EFOO]; char b[EBAR]; });
>   #undef EFOO
>   #undef EBAR
>   const EFOO = eEFOO;
>   const EBAR = eEBAR;
>
>  Very much like that.
>  ok? I was probably going to do this tonight for cygwin/openbsd/amd64.
>
>  - Jay
>
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] making Uerror "portable"?
> Date: Mon, 12 Jan 2009 11:13:16 +1100
>
>
> 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/4e999f93/attachment-0002.html>