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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Real_Time.Time_First Date: Wed, 9 Dec 2020 16:21:02 +0200 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net pUnRlFiQei2k/uIn60Mtzw14asg9YquyR0Wlowz5LIFroRBeMk Cancel-Lock: sha1:ICljoB9QFqNh4yKfOx7YjjwQvBY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:60771 List-Id: 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