[M3devel] m3core/unix directions

[Jay K]

m3core/unix directions

 


My intent here is to further reduce platform dependencies and header cloning.
I know there isn't much left, but there is some.

 


In particular:
  eliminate struct_timespec (done)


  eliminate struct_timeval (partly done, more to do)
    implies eliminating select wrapper  
    implies eliminating gettimeofday wrapper  


  eliminate MAX_FDSET  

     Though there is a possible bug workaround in m3core, that Interix's header is wrong.


  eliminate time_t (I'd also like to find some way to get 64bit time_t everywhere,
   though my research so far says it isn't available)


  eliminate struct_tm  

     Mainly used by m3core/src/time.

     As well as fix m3-mail/webcard, m3-mail/postcard which have crashing bugs due to declaring their own form.


  eliminate struct_sockaddr_in  


  maybe eliminate struct_sockaddr_un (I know it was requested)  


  eliminate all of the Usysdep.i3 files (MAX_FDSET, struct_tm)  


  maybe eliminate ioctl/fcntl; there are precious few uses; is the Solaris bug workaround 
    for them needed? That bug workaround is a good reason to keep the wrappers.


  maybe eliminate stat; there there again there are interesting bug workarounds in
    the wrappers, the incorrect headers I had for Darwin/arm 

 

  maybe reduce what all m3core/src/unix provides/wraps, leave it to the clients;

    however to the extent that they are just const char* and int, probably ok

    to just leave asis (e.g. open/read/write/close)

 


I'm not sure I'll succeed at all of this, but each step I believe has value.
General strategy is to push C up one level. Pass around types
 that we have complete control of.

 


There is always C below the Posix ports of Modula-3, as well as the Win32/NT port.
It is "just" a matter at where the line is.

 


A hypothetical Modula-3 "OS" wouldn't necessarily use any of this C, if it
provided m3core/libm3/tcp directly.

 


btw, here's a likely example of the bugs these patterns have caused:

 


C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(77):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion
C:\dev2\cm3.2\m3-www\http\src\AppBackup.m3(103):(* Nov 16: file.lock broken in call to fcntl - int vs. long confusion

 


To mitigate appearance of hypocrisy, I'm willing to do this work on the Win32 header clones also.
Though I think they are a smaller and bigger problem.
Bigger because we have cloned *a lot*.
Smaller because they vary less across the various Win32 architectures.
Similar in size because we use only a small part of them, analogous to what we use for Unix.

 


I speculate that stuff like OpenGL and X Windows aren't as problematic because
they are fairly independent of OS/kernel.
It is the "libc as kernel wrapper" where the problems are worse, given the
  relatively large number of varieties (Linux, *BSD, NT, Solaris, Darwin).
Though they could still embed e.g. time_t, struct timeval, etc.

 

 

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100411/35c5d3f6/attachment-0001.html>