Re: Ada.Real_Time.Time_First

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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.

>     Quad_Is_Flying :=
>       Ada.Real_Time.To_Duration (Now - Last_Flight_Command_Time)
>         < In_Flight_Time_Threshold;


If Time_First, as the initial value of Last_Flight_Command_Time, would 
really be in the far past compared to Now, that computation risks 
overflowing the range of Duration, which may be as small as one day 
(86_400 seconds), RM 9.6(27).

> The workround I used was
> 
>     Quad_Is_Flying :=
>       Last_Flight_Command_Time /= Ada.Real_Time.Time_First
>         and then
>       Ada.Real_Time.To_Duration (Now - Last_Flight_Command_Time)
>         < In_Flight_Time_Threshold;
> 
> In other words, I was using Time_First as a flag to indicate that
> Last_Flight_Command_Time was invalid.


Even that can still overflow Duration, if more than one day can pass 
since the last flight command.

> What would your standard pattern for this sort of problem be?
> Esepecially considering that if I make Time_First a large negative
> number I'll get the opposite problem, e.g. predicting ahead for a very
> large interval, possibly even leading to numeric overflows.


You have two problems: your assumption about Time_First (or perhaps it's 
not an assumption, if you make your own RTS) and the possible overflow 
of Duration.

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.

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.


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