[M3devel] making Uerror "portable"?

[Jay]

  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;  
 
  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.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: 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.eduTo: m3devel at elegosoft.comSubject: making Uerror "portable"?Date: Thu, 8 Jan 2009 06:36:44 +0000I've been thinking about "fixing" Uerrorto remove the system-dependentness of it. I have about given up. There are multiple easy options, but theyall have downsides that make me think itmight 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 requireconstants. The following are some of the possible changes,that make porting to basically any future systembe a no-op in this area, except for the occasional missing or possiblyequal 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 neededto 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/38d30b9d/attachment-0002.html>