From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Path: eternal-september.org!reader02.eternal-september.org!aioe.org!0nYzhFpEeoH2MFWixtUlcg.user.gioia.aioe.org.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Ada.Real_Time.Time_First
Date: Wed, 09 Dec 2020 20:16:24 +0000
Organization: Aioe.org NNTP Server
Message-ID: <lyk0tqenvr.fsf@pushface.org>
References: <lyv9dbduvf.fsf@pushface.org> <i3c4qgF63ncU1@mid.individual.net>
NNTP-Posting-Host: 0nYzhFpEeoH2MFWixtUlcg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin)
Cancel-Lock: sha1:/QUjA9NOKXrAJzPX+ug/ovBrYUo=
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader02.eternal-september.org comp.lang.ada:60774
List-Id: <comp.lang.ada>

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2020-12-09 14:30, Simon Wright wrote:
>> I opened an issue[1] on Cortex GNAT RTS, saying
>>     You’d expect Ada.Real_Time.Time_First to be quite a long time
>>     before any possible value of Ada.Real_Time.Clock; but in fact the
>>     system starts with Clock equal to Time_First.
>
>
> I don't see any reason for expecting Time_First to be far in the past
> relative to program start. In fact, RM D.8(19) says "For example, [the 
> start of Time] can correspond to the time of system initialization".
>
> Contrariwise, it could be useful to know that Clock actually starts
> from Time_First, because I have often needed a "Start_Time" object
> that records the Clock at the start of the program, and it would be
> much simpler to use Time_First, if Time_First is known to equal the
> initial Clock.

OK, I'll back out that last commit!

> To indicate an invalid Last_Flight_Command_Time, I would either use a
> discriminated type wrapping a Time value that depends on a Valid 
> discriminant, as you suggested, or just have a Boolean flag, say
> Flight_Commands_Given that is initially False. I would use the 
> discriminated type only if there is more than one such variable or
> object in the program.

Yes.

> For the overflow, I suggest changing the comparison to
>
>    Now < Last_Flight_Command_Time
>          + To_Time_Span (In_Flight_Time_Threshold)
>
> assuming that Last_Flight_Command_Time is valid in the sense we are
> discussing. That will overflow only when Last_Flight_Command_Time 
> approaches Time_Last, and the program is likely to fail then anyway.

This conversation has been very valuable, particularly in the case of
other similar tests. I suspect, though, that "are we still flying?" is a
question that'll take more thinking to resolve!

>> [1] https://github.com/simonjwright/cortex-gnat-rts/issues/33