Re: Ada.Real_Time.Time_First

[Simon Wright <simon@pushface.org>]

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