[M3devel] Utime.struct_tm

[Jay K]

struct_tm = RECORD

tm_sec: int;

tm_min: int;

tm_hour: int;

tm_mday: int;

tm_mon: int;

tm_year: int;

tm_wday: int;

tm_yday: int;

tm_isdst: int;

 

 

(* here *) 

 

 

tm_gmtoff:INTEGER;

tm_zone: char_star;

END;

  

　  

The fields after tm_isdst are not always present, and perhaps not always in that order.

Portable code, Modula-3, C, or otherwise, cannot refer to those last two fields.

C can do it with #ifdefs or autoconf-assisted and with some alternative if they are not present.

  　

  

What to do?

Generally the vast majority of platform-dependency should and has been removed

from the system, for much easier (and therefore generally more correct) porting.

　  

  

 

Today we declare struct_tm per-target.

Most targets do declare the fields, but:

Cygwin, Irix, HP-UX, Interix, Solaris do not.

"Most" therefore leaves at least Linux, *BSD, Darwin. 

I do hope to bring up a few more targets, which may contribute

to one set or the other.

  

  　

And I just checked that Solaris really doesn't provide the fields in C, so

we can claim that mainstream platforms are part of the "problem".

  

　  

There are a few options:

  - leave it as system-dependent; my least favorite  

 

  - define it to have the common prefix and provide copying C wrappers  

  This allows for some portable uses. You can't just define the common  

  prefix and allow direct calls, as that would corrupt the stack where it is an output.  

  This would not allow for embedding the struct in any target-defined structs, but that probably never occurs.  

 

  - remove it from m3core and all functions that traffic in it -- localtime, mktime, etc. 

  This is my favorite. ok?   

  Anyone that needs this functionality can chose from using interface Date, or writing portable C.  

  I'm going to go ahead and do this. ok?

　

  And in any case, rewrite m3-libs\m3core\src\time in #ifdef'ed C, at least wherever struct_tm is used. 

  I'm going to go ahead and do this. ok?

　

 

 

- Jay

 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090919/7287bf23/attachment-0001.html>