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: 103376,f948976d12c7ee33 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-04 09:57:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Boeing and Dreamliner References: <3EFC6FC2.B96DAEA4@adaworks.com> <1056731513.272294@master.nyc.kbcfp.com> <3EFF2F6D.3793971@adaworks.com> <3F005D54.5090104@cogeco.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 04 Jul 2003 12:42:04 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1057336926 198.96.223.163 (Fri, 04 Jul 2003 12:42:06 EDT) NNTP-Posting-Date: Fri, 04 Jul 2003 12:42:06 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:40064 Date: 2003-07-04T12:42:04-04:00 List-Id: Dave Thompson wrote: > On Mon, 30 Jun 2003 11:55:00 -0400, "Warren W. Gay VE3WWG" > wrote: > [snip] > >>I would disagree with your position on the basis that even where code >>is carefully scrutinized, within Ada you have the advantage of builtin >>language features to check areas that you might neglect (while developing >>and testing at least, prior to checks being turned off). >> >>For example, where a short (16 bit integer) in C/C++ might hold the >>value -32768, and be negated and assigned to a short result, this >>operation might be undefined (I am not sure if any newer standard like >>C99 addresses this). On some implementations at least, that result is >>silently set to 0, which clearly is incorrect! In Ada, this cannot be >>ignored without deliberately working around it (or turning the checks >>off). > > In C and C++ short is _at least_ 16 bits, but may be more, and > negation (prefix '-') is done after (at least virtually) applying the > integral promotions, which includes short to int. > > If int is also 16bit 2sC capable of representing -32768 but not > +32768, which is legal but increasingly rare, then the negation > is overflow and undefined behavior, which may theoretically do > anything, and in particular no check or diagnostic required. > This is the same in C89, C99, and C++98. In practice it is > expected that if the platform has a negate (or subtract) > instruction or function that works correctly for nonoverflow > cases, the C compiler will just use it and accept whatever > it does for overflow, which is typically either a wrong value, > almost always a wrapped value, or some trap or signal. > > If short is 16bit but int is larger (e.g. 32bit) then the (promotion > and) negation is well-defined, and the narrowing assignment to short > produces an implementation-defined result in C89 or C++98, > and either an implementation-defined result or an implementation- > defined signal in C99; implementation-defined means it must be > documented. Still no check or diagnostic is required, unless the > implementor chooses to doument such, but it is required that > you either get some value or in C99 only some definite signal > which (presumably?) can be caught by a signal() routine although not > necessarily recovered/resumed; you may not get arbitrary weirdness or > crash. FWTW. > > These cases can be distinguished, if necessary, at or before compile > time by checking the values in . > > - David.Thompson1 at worldnet.att.net So what this says, in the end, is that it is up to the programmer to make these "checks" and to "do the right thing". This is clearly one specific area that Ada has a advantage in safety. Unless you run/test your code with the checks deliberately turned off, you will discover this little gem immediately (assuming that you encounter the right data, that is). Conversely, in C/C++, this "undefined behavior" may go completely unnoticed, until it has a disasterous side effect somewhere else down the line. This is the precise scenario I ran into when porting some C code into Ada some time ago. The SOX C code was oblivious to this "error", but the Ada code that I ported caught it. So this was a real example of the C programmer failing to "do the right thing", and Ada forcing _this_ programmer to do "the right thing." ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg