[M3devel] Modula-3/C interop in Date/Time?

Sat Apr 17 04:44:39 CEST 2010

The use case is the TimeZone's in DatePosix.m3.

It's not a big deal.

There are just two constant timezones, "local", and "utc", identified by references to integers: NIL, ^ = 1 and ^ = 0. Where NIL is interpreted as 0 or 1. It could just be an enum, but the public type is REFANY and it is revealed in the Win32 flavor to actually be a reference to something else. I could maybe change that. But what is the effect on pickles either way?

The Win32 one isn't picklable in either case?? I'm not sure. So Timezone isn't portably pickable? And therefore pickles of Posix timezones can be broken? If they were to be pickled, I think the representation is dubious -- probably should pickle the "offset" from GMT/UTC, not 0 or 1.

The Win32 code is also dubious given evolution of the Win32 API over the years. It is more flexible now and I wonder if that implies the old API was insufficient.

(Though "local" can change in time, not really "constant", as the daylight savings cutoff is crossed, or indeed when I travel with a computer and stuff says running but "asleep" and then "resumed". I'm quite suspicious that lots of code doesn't account for timezone changes. I'm also quite suspicious of any code that does anything timezone sensitive or uses "local" time for anything. Using GMT/UTC for everything, except display, is the way to go. It makes things vastly simpler and better defined. Could be that Unix/Posixy stuff is generally ok. Could be just an historical bogus favoring of localtime on PCs (and Macs?).)

I actually strongly suspect as well that we can get by with just the one Posix implementation of this stuff, no BSD, no Win32.

In particular, msvcr*.dll does expose tzname, timezone, daylight. Besides of course "small" localtime/gmtime.

Have to think though "Time" vs. "Date".

Win32 epoch is earlier, which is useful for representating dates in the past.

Basically "this stuff" is more about "Date" and less about "Time", though they interact.

I'm pretty sure we have bugs as well where we assume the current "daylight" status applies to all times/dates.

Switching to "time64" is part of the equation.

Maybe I should attack more from that angle. Make things work for Date{year := 2040} and see what all that implies.

 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 16 Apr 2010 10:30:48 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Modula-3/C interop in Date/Time?

What is the use-case here?

Merely having UNTRACED references doesn't make your code unsafe.  Using ADR does.

But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C.

e.g., C function

f(int *ref p)

can be declared as

<*EXTERNAL*> f(VAR i: INTEGER)

and this is still safe.

On 16 Apr 2010, at 04:18, Jay K wrote:

Isn't making them unsafe? ADR? I'll try..

- Jay

> To: jay.krell at cornell.edu
> Date: Fri, 16 Apr 2010 00:00:34 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
> 
> I don't think there's anything unsafe about UNTRACED.
> 
> It's DISPOSE that's unsafe...
> 
> Mika
> 
> Jay K writes:
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_
> >Content-Type: text/plain; charset="iso-2022-jp"
> >Content-Transfer-Encoding: 7bit
> >
> >But then unsafe, right?
> >
> > - Jay
> >
> >> From: hosking at cs.purdue.edu
> >> Date: Thu, 15 Apr 2010 22:06:14 -0400
> >> To: rodney_bates at lcwb.coop
> >> CC: m3dev el at elegosoft.com
> >> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
> >> 
> >> Indeed! UNTRACED.
> >> 
> >> 
> >> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
> >> 
> >> > Since these pointer variables are initialized by
> >> > C code and their referents are also provided by C code
> >> > as global variables, shouldn't the type be untraced?
> >> > 
> >> > I suppose that, since they don't point into the traced
> >> > heap, the collector implementation we have would quietly
> >> > ignore them as roots. But that's relying on implementation-
> >> > dependent information.
> >> > 
> >> > Also, if someone created a field of type Date.TimeZone,
> >> > (or an array of them) in a traced-heap-allocated object,
> > > which is a perfectly legitimate thing to do, what would
> >> > our collector do then?
> >> > 
> >> > 
> >> > 
> >> > Jay K wrote:
> >> >> Is this legal/correct?
> >> >> 
> >> >> 
> >> >> Date.i3:
> >> >> TYPE TimeZone <: REFANY;
> >> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> >> >> 
> >> >> 
> >> >> Date.m3:　
> >> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> >> >> 　
> >> >> 
> >> >> DatePosixC.c:
> >> >> static const int Local = 0& #59;
> >> >> static const int UTC = 1;
> >> >> extern const int const * const Date__Local = &Local;
> >> >> extern const int const * const Date__UTC = &UTC;
> >> >> 　
> >> >> 
> >> >> - Jay
> >> 
> > 
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_
> >Content-Type: text/html; charset="iso-2022-jp"
> >Content-Transfer-Encoding: 7bit
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px;
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt;
> >font-family:Verdana
> >}
> >--></style>
> ></head 2;
> ><body class='hmmessage'>But then unsafe, right?<br><br> - Jay<br><br>> From: hosking@cs.purdue.edu<br>> Date: Thu, 15 Apr 2010 22:06:14 -0400<br>> To: rodney_bates&
> >#64;lcwb.coop<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<br>> <br>> Indeed! UNTRACED.<br>> <br>> <
> >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<br>> <br>> > Since these pointer variables are initialized by<br>> & #38;#62; C code and their referents are also provided by C
> > code<br>> > as global variables, shouldn't the type be untraced?<br>> > <br>> > I suppose that, since they don't point into the traced<br>> > heap, the collect
> >or implementation we have would quietly<br>> > ignore them as roots. But that's relying on implementation-<br>> > dependent information.<br>> > <br>> > Also, if someon
> >e created a field of type Date.TimeZone,<br>> &#62
> > ; (or an array of them) in a traced-heap-allocated object,<br>> > which is a perfectly legitimate thing to do, what would<br >> > our collector do then?<br>> > <br>
> >> > <br>> > <br>> > Jay K wrote:<br>> >> Is this legal/correct?<br>> >> <br>> >> <br>> >> Date.i3:<br>> >> TYPE TimeZone
> > <: REFANY;<br>> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<br>> >> <br>> >&# 38;#62; <br>> >>
> > Date.m3:　<br>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;<br>> >> 　<br>> >> <br>> >> DatePosixC.c:<br>
> >> >> static const int Local = 0;<br>> >> static const int UTC = 1;<br>> >> extern const int const * const Date__Local = &Local;<br>>
> > >> extern const int con st * const Dat
> > e__UTC = &UTC;<br>> >> 　<br>> >> <br>> >> - Jay<br>> <br> </body>
> ></html>
> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100417/83e4817b/attachment-0002.html>