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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,b8d52151b7b306d2 X-Google-Attributes: gidf849b,public X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-28 23:43:57 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!peernews3.colt.net!news0.de.colt.net!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.arch.embedded,comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Date: Mon, 29 Dec 2003 07:43:56 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <$km9afA3DB7$EAYO@phaedsys.demon.co.uk> <3feda44e_3@mk-nntp-1.news.uk.worldonline.com> <3fedbbf0_3@mk-nntp-1.news.uk.worldonline.com> <3fef5f9b_2@mk-nntp-1.news.uk.worldonline.com> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1072683836 3193 134.91.1.34 (29 Dec 2003 07:43:56 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Mon, 29 Dec 2003 07:43:56 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.arch.embedded:6271 comp.lang.ada:3917 Date: 2003-12-29T07:43:56+00:00 List-Id: In comp.lang.ada Robert I. Eachus wrote: : Ian Bell wrote: : :> So are you basically saying that Ada requires the function return type to be :> bounded and can simply check this against the array bound? : : No. He is saying that Ada types and subtypes typically contain : information about expected values that will be checked at compile time : or run time as appropriate. I'll try one of Robert's ideas. Say I do not ignore the compiler's warning that the function used for array indexing will return values out of range for the array. I might see that the choice of two subtypes has been inappropriate and should be replaced with two different types. They will have overlapping ranges but will allow the same representation in bits. However, the program cannot be compiled any longer, using the same buffer: procedure p is type Red_Index is range 90 .. 105; type Light_Red_Index is range 100 .. 120; buffer: array(Red_Index) of Boolean; function some_val return Light_Red_Index is separate; begin if buffer(some_val) then null; -- do something here, in a more real program end if; end p; 11. if buffer(some_val) then | >>> expected type "Red_Index" defined at line 3 >>> found type "Light_Red_Index" defined at line 4 That is, I might presume that color Red is not too different from Light_Red. I might know that the number of bits used for values in the two types will be the same (char in C terms, say). Still the compiler will not let me use Light_Red_Index's value 101 and Red_Index's value 101 interchangeably. The range check goes away when both the function and the array use the same index type (the function is implemented to return random values from the index type's range (because the generator has been instantiated with that type.)) The assembly listing shows 8bit register use on i686 when the index range permits, even with numbers ranging beyond 255 (or > 65535 for that matter). type Light_Red_Index is range 92_000 .. 92_200; for Light_Red_Index'Size use 8; In short, convenient, checked at compile time, and efficient :-) -- Georg