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.42.110.5 with SMTP id n5mr44125830icp.22.1430696987517;
        Sun, 03 May 2015 16:49:47 -0700 (PDT)
X-Received: by 10.50.1.43 with SMTP id 11mr106159igj.8.1430696987505; Sun, 03
 May 2015 16:49:47 -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!l13no13485903iga.0!news-out.google.com!kd3ni7465igb.0!nntp.google.com!l13no13485898iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 3 May 2015 16:49:46 -0700 (PDT)
In-Reply-To: <9f20f713-d65c-471d-ab7c-d314a14fdcd0@googlegroups.com>
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3cbf7f4e-304c-4c26-8d99-0087b8c15e7a@googlegroups.com>
Subject: Re: Boeing 787 integer overflow
From: robin.vowels@gmail.com
Injection-Date: Sun, 03 May 2015 23:49:47 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:25709
Date: 2015-05-03T16:49:46-07:00
List-Id: <comp.lang.ada>

On Sunday, May 3, 2015 at 9:23:45 PM UTC+10, Maciej Sobczak wrote:
> W dniu niedziela, 3 maja 2015 01:34:59 UTC+2 u=C5=BCytkownik Robert Love =
napisa=C5=82:
>=20
> > Ars Tecnica has this article:
> >=20
> > http://arstechnica.com/information-technology/2015/05/01/boeing-787-dre=
amliners-contain-a-potentially-catastrophic-software-bug/=20
> >=20
> >=20
> > Can anyone comment on what language Boeing used for this?
>=20
> 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 mainten=
ance more frequently than that anyway), so there was no need to implement a=
 solution for this. You can safely argue that the capacity of the counter a=
llows proper operation within the given bounds and you could even have that=
 tested with 100% coverage of the *required* data/time domain and (why not?=
) formally verified as well.
>=20
> > If Ada, would a modular integer be more appropriate?
>=20
> Why? Are you aware of the requirement that the counter has to automatical=
ly reset after (let's say) half a year? I guess not and even if you attempt=
 to make it up as a derived requirement, it might be superfluous or even co=
ntradictory to other requirements.
>=20
> > Is there an=20
> > exception handler for this integer?
>=20
> Why? Are there any requirements that explicitly state the plane has to wo=
rk continuously for longer than 8 months?

It won't be in the air for 6 months, but the software may be running
for that time, or the counter is running continuously.