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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c0f035b936128b6c
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Ada95 to ANSI_C converter
Date: 1997/04/03
Message-ID: <dewar.860115225@merv>#1/1
X-Deja-AN: 230563523
References: <5hbrah$ctt$1@gail.ripco.com> <JSA.97Apr2144544@alexandria>
 <dewar.860070899@merv> <JSA.97Apr3134856@alexandria>
 <E831sB.M4s@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-03T00:00:00+00:00
List-Id: <comp.lang.ada>


Bob said

<<Anyway, I think Robert is correct in that machine code (for most
machines) can catch overflows efficiently, whereas ANSI C cannot.
Particular implementations of C might be able to.  So there's something
"fundamental" about this inefficiency, if we're talking about standard,
portable C.
>>

The implementation tricks that Bob refers to can alleviate some of the
cost of overflow checking, but by no means all, on any architecture
that I can imagine. One can always of course build a C compiler that
specifically recognizes "overflow patterns", and reliably generate
optimal code with the check -- I know of no such C compiler.

I will make the statement once more, unconditionally and clearly: The
decision to generate C, rather than object code directly, involves
a number of fundamental inefficiencies, one of which is overflow checking!

I have not seen anything that contests this position!