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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-30 09:10:15 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!newspeer1.nwr.nac.net!solnet.ch!solnet.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.com!t-online.de!news.t-online.com!not-for-mail From: Martin Krischik Newsgroups: comp.arch.embedded,comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems Followup-To: comp.arch.embedded,comp.lang.ada Date: Tue, 30 Dec 2003 18:08:23 +0100 Organization: AdaCL Message-ID: <1731094.1f7Irsyk1h@linux1.krischik.com> References: <3fe00b82.90228601@News.CIS.DFN.DE> <3FE026A8.3CD6A3A@yahoo.com> <3bf1uvg2ntadvahfud2rg6ujk24sora6gr@4ax.com> <2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com> <20619edc.0312221020.3fd1b4ee@posting.google.com> <20619edc.0312222106.3b369547@posting.google.com> <45cs9hAbLc6$EAAx@phaedsys.demon.co.uk> <3fe9f0d7.104475725@News.CIS.DFN.DE> <5802069.JsgInS3tXa@linux1.krischik.com> <1072464162.325936@master.nyc.kbcfp.com> <1563361.SfB03k3vvC@linux1.krischik.com> <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE> <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE> Reply-To: krischik@users.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.t-online.com 1072804196 01 7494 BYGvG6rlqGqR4Yt 031230 17:09:56 X-Complaints-To: usenet-abuse@t-online.de X-ID: VxxlOsZOYeIHqMSE9YXuzp+yLp1b1kA8FsB3f-YfS9VO2JCll+doQN User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.arch.embedded:6361 comp.lang.ada:3952 Date: 2003-12-30T18:08:23+01:00 List-Id: Dave Hansen wrote: > On Tue, 30 Dec 2003 11:18:55 +0100, Martin Krischik > wrote: > >>Dave Hansen wrote: > [...re: plain, signed, and unsigned char...] >>> All three are integer types. All three are 1 byte wide ("byte" does >>> not mean "8 bits"). >> >>That is why Ada 'Size gives you the size in bits. No misunderstanding >>here. > > In C, CHAR_BIT gives you the number of bits in [[un]signed] char. It > must be >= 8. > >> >>>>>If you are lucky you have real C99 compiler with byte. >>> >>> I'm not sure what you mean. There's no such thing as "byte." >>> uint8_t? Not guaranteed to exist. unint_least8_t? That would work, >>> but I fear relatively few even know it exists, let alone how to use >>> it... >> >>You allwas learn something new. But unint_least8_t is not helpfull for >>safety-critical embedded systems. You might need exaclty 8 bit. > > If a platform supports uint8_t (unsigned integer exactly 8 bits wide) > the compiler must provide the type. If the platform does not support > the type, you have to choose another platform. > >> >>Which brings me back to the original Question. How will you do this in C: >> >>type Month is new Integer range 1 .. 12; >>for Month'Size is 8; > > You could do something like > > typedef struct month{ > value:8; > } Month; > >> >>Or even better: >> >>type Display_Element is Interger range 0 .. 9; >>for Display_Element'Size use 4; > > typedef struct display_element{ > value:4; > } Display_Element; >>type Display_Array is array (Integer range 1 .. 6) of Display_Element; >>pragma Pack (Display_Array); > > typedef struct display_array{ > elt0: 4; > elt1: 4; > elt2: 4; > elt3: 4; > elt4: 4; > elt5: 4; > } Display_Array; I had my array start at 1 not 0. In C all numbers start with 0 but in the real world they usualy start with 1. >>Display : Display_Array; >>for Display'Address use 16#12_3456#; > > Display_Array *Display = (Display_Array *) 0x123456; Display_Array *const Display = (Display_Array *) 0x123456; > Though in no case would the ranges be enforced. Heck, enumerations > aren't enforced in any way either: > > enum { Red, Green, Blue } color; > int number; > > color = 42; > number = Red; > > Is perfectly fine as far as the compiler is concerned. > >>We are talking "safety-critical embedded systems". The Plane might crash >>if 11 is ever stored in a Display_Element. > > Then don't do that. ;-) But is it not much better if the compiler stoped you from doing that mistake? Anyway, all above is is just plain C and it is not at all as save as the Ada code. Nor is it as easy to read (safety-critical software in my book should be code reviewed). And this is just The claim here in the group is that by use of a static analysis tool the C code can be made as secure as the Ada code. So let me expand my question: How with the static analysis tool find out the the follwing might lead to the plane crashing. Ada: Display (1) = 11; -- Compiler will warn you compile time Display (2) = Value + 2; -- exeption if Value is greater 7 C: Display->elt0 = 11; Display->elt1 = Value + 2; This example might be over primitive but humans somtimes make this little mistakes. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com