[M3devel] inconsistencies in external interfaces

[Jay]

1) I THINK these files are often a pretty direct translation of /usr/include, dead stuff, comments, and all. Posix often mandates that certain types are certain headers, even if they aren't used by any function in that header.

 

 

Utime.i3 would declare time_t not necessarily for its own purposes but so that C code (nonsense example but ok):

 

 

#include <time.h>

 

int main()

{

  time_t t = 0;

  /* ... */

}

 

 

translates "directly" to Modula-3 (ha):

 

 

IMPORT Utime;

VAR

  t: Utime.time_t := 0

BEGIN

  (* ... *)

END Main.

  

2) Almost everything in m3core/src/unix is dead anyway, outside of the common directory, and Usysdeps.i3, and the userthread support.

Look at the m3makefile. It is mostly if'ed out.

The only active platforms using their own full assortment of cloned /usr/include are I386_DARWIN and AMD64_DARWIN..until I get around to them. If OpenDarwin/x86 7.0 will run in a VM, I386_DARWIN will fall soon. AMD64_DARWIN must wait for additional hardware, or someone else to switch it (Tony?)

 

 

 - Jay

 
> To: m3devel at elegosoft.com
> Date: Fri, 24 Apr 2009 20:41:04 -0700
> From: mika at async.caltech.edu
> Subject: [M3devel] inconsistencies in external interfaces
> 
> 
> All right, here's another little oddity.
> 
> m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following:
> 
> time_t = int; (* seconds since the Epoch *)
> 
> ...
> 
> <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star;
> 
> Huh? What's the point of declaring time_t if you're not going to
> use it?
> 
> (I think it used to be that long_star and time_t resolved to the
> same type, before the LONGINT work or some other foreign interface
> updating, but they no longer seem to...)
> 
> Mika
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090425/1047bb2f/attachment-0002.html>