From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.43.130.198 with SMTP id hn6mr41911849icc.26.1430697243751;
        Sun, 03 May 2015 16:54:03 -0700 (PDT)
X-Received: by 10.50.4.34 with SMTP id h2mr106185igh.7.1430697243738; Sun, 03
 May 2015 16:54:03 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!l13no13486582iga.0!news-out.google.com!kd3ni7465igb.0!nntp.google.com!l13no13486575iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 3 May 2015 16:54:03 -0700 (PDT)
In-Reply-To: <alpine.CYG.2.11.1505031156210.3716@WIL414CHAPIN.vtc.vsc.edu>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=123.2.70.40;
 posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le
NNTP-Posting-Host: 123.2.70.40
References: <201505021834588468-rblove@airmailnet>
 <9f20f713-d65c-471d-ab7c-d314a14fdcd0@googlegroups.com>
 <alpine.CYG.2.11.1505031156210.3716@WIL414CHAPIN.vtc.vsc.edu>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3e8a4ac6-b0cd-445d-8e9c-82ce8f7f9fee@googlegroups.com>
Subject: Re: Boeing 787 integer overflow
From: robin.vowels@gmail.com
Injection-Date: Sun, 03 May 2015 23:54:03 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:25710
Date: 2015-05-03T16:54:03-07:00
List-Id: <comp.lang.ada>

On Monday, May 4, 2015 at 2:03:55 AM UTC+10, Peter Chapin wrote:
> On Sun, 3 May 2015, Maciej Sobczak wrote:
> 
> >> Can anyone comment on what language Boeing used for this?
> >
> > It does not matter. The ability to run continuously for 8 months was 
> > most likely not in the requirements (planes have to be switched off for 
> > maintenance more frequently than that anyway), so there was no need to 
> > implement a solution for this.
> 
> I guess it depends on if there is a *requirement* to reboot the system 
> periodically (less than 8 months) in the maintenance plan. The matter 
> should be handled somewhere and it seems like it wasn't. In other words it 
> was just "luck" that these systems have been getting restarted frequently 
> enough.
> 
> Planes obviously don't fly for 8 months straight and I'm sure they get 
> maintained, in general, more regularly than that as well. I don't know 
> precisely which system this issue is connected with, but it seems possible 
> to me that, in some cases at least, some systems would be left up and 
> running while others are being maintained. In other words a daily 
> maintenance schedule may not imply that the counter in question is getting 
> reset daily.
> 
> A software fix might be nice, such as increasing the counter to 64 bits to 
> push the overflow time out to something ridiculous,

That isn't the solution.
The solution is to have an appropriate error handler.

> but just adding an 
> item to the maintenance checklist might also be sufficient.

Things like that get overlooked.
Maybe not this year, but in 10 years, when everyone has forgotten about it.