[M3devel] utime.i3 and imported data

[Tony Hosking]

Aren't these all superseded by gettimeofday?

I say just not support the global variable access.

Utime.i3 on other platforms does not have these globals.

On Feb 12, 2008, at 12:07 PM, Jay wrote:

> well..we were accessing fields at the end of struct tm that aren't  
> there..switched from DateBsd to DateLinux and now my exact first  
> proposal stands. :)
>
> I worked around but it is lame, imho more lame than my suggestion.
> My suggestion still imports/shares the data, just via a C function  
> call, so that the right declarations are present.
> The right declarations are..difficult in Modula-3.
> You'd have to declare the variables as pointers and change their  
> name, and then somehow either layer portable code over that, or  
> fork DateBsd/DateLinux to DateCygwin..which I just don't think is  
> worth it. I don't like per-platform forks, too much duplicity, too  
> much multiplication out of code, too much code, too much cruft, too  
> little maintenance.... better to merge stuff if it isn't a mess and  
> have less overall source code to maintain....
>
>  - Jay
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Subject: RE: [M3devel] utime.i3 and imported data
> Date: Tue, 12 Feb 2008 16:27:38 +0000
>
> sorry, still not a bad idea, but not where my crash is.
> I wasn't paying close enough attention. Those aren't used on NT386GNU.
> The crash is probably here:
>
> C:\dev2\cm3.2\m3-libs\m3core\src\time\posix\DateBsd.m3(47):       
> date.zone    := M3toC.CopyStoT (tm.tm_zone);
>
> I don't know why yet. (meta reason -- these time formats aren't  
> worthwhile even if forward slashes in paths and X Windows are....)
>
>  - Jay
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Date: Tue, 12 Feb 2008 15:57:25 +0000
> Subject: [M3devel] utime.i3 and imported data
>
> For good reason, imported (dynamically linked) data doesn't work  
> great on Win32.
> Functions work much better. Data can work, but you generally need  
> the header to say __declspec(dllimport), to change it to a  
> declaration of a pointer. I've seen GNU ld has some workaround but  
> I'm not familiar with it, it doesn't worthwhile to me, and I'm  
> having a problem.
>
> I strongly suggest all the Utime.i3:
>
> <*EXTERNAL*> VAR timezone: time_t;
> <*EXTERNAL*> VAR daylight: int;
> <*EXTERNAL*> VAR tzname: ARRAY [0..1] OF char_star;
>
> be changed to functions:
>
> <*EXTERNAL Utime__get_timezone*> get_timezone(): time_t;
> <*EXTERNAL Utime__get_daylight*> get_daylight(): int;
> <*EXTERNAL Utime__get_tzname*> get_tzname(a: [0..1]): char_star;
>
>
> with an implementation in C:
>
> UtimeC.c
> #include <time.h>
> time_t Utime__get_timezone(void)
> {
>     return timezone;
> }
>
> int Utime__get_daylight(void)
> {
>     return daylight;
> }
>
> char* Utime__get_tzname(unsigned a)
> {
>     return tzname[a];
> }
>
> for now I'm going to try another workaround..where NT386GNU has  
> this data as not external and some C code to call tzset and then  
> copy the data from the C globals to Modula-3 globals.
>
> The datetime feature I added to Quake is crashing, I think due to  
> this...
>
>  - Jay
>
> Shed those extra pounds with MSN and The Biggest Loser! Learn more.
> Helping your favorite cause is as easy as instant messaging. You  
> IM, we give. Learn more.
> Connect and share in new ways with Windows Live. Get it now!