[m-rev.] for review: Uncomment foreign code definition for clock/3.

Julien Fischer jfischer at opturion.com
Wed May 25 10:27:55 AEST 2016


On Tue, 24 May 2016, Sebastian Godelet wrote:

>> diff --git a/library/time.m b/library/time.m index bf4caad..ea9c569 100644
>> --- a/library/time.m
>> +++ b/library/time.m
>> @@ -264,16 +264,14 @@ time.clock(Result, !IO) :-  "
>>      Ret = (MR_Integer) clock();
>>  ").
>> -/* XXX need to add System.dll to the references list.
>>  :- pragma foreign_proc("C#",
>>      time.c_clock(Ret::out, _IO0::di, _IO::uo),
>>      [will_not_call_mercury, promise_pure, tabled_for_io],  "{
>>      // XXX Ticks is long in .NET!
>> -    Ret = (int) System.Diagnostics.Process.GetCurrentProcess
>> -        .UserProcessorTime.Ticks;
>> +    Ret = (int) System.Diagnostics.Process.GetCurrentProcess().
> Well the XXX is not addressed in this issue, the reason why ticks is using 64-bit integers
> in .NET is that it is based on 100-nanosecond intervals, which get large pretty fast,
> but I guess there is a reason why clock_t is a public alias for int (IMHO it should be an abstract type
> depending on the backend).

I suspect the reason may simply be that that module predates the
addition of foreign_type pragmas to the language.   (Indeed, it predates
the addition of the non-C backends as well.)

I agree that it should be an abstract type.  (I'm present running a
check to see what actually depends on the definition of clock_t being


More information about the reviews mailing list