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,f2ee53e7ad4c80d
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Interfacing Ada and C (exceptions) for safety-related systems.
Date: 1998/07/23
Message-ID: <dewar.901221183@merv>#1/1
X-Deja-AN: 374275426
References: <35B71908.74CD212E@amst.co.at>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 901221292 23120 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-07-23T00:00:00+00:00
List-Id: <comp.lang.ada>

<<After first tests calling C from Ada (using ObjectAda for
Realtime ETS and Microsoft Visual C++) we found,
that errors in C (which are not totally impossible in our code,
like zero division, range checks, pointer problems)
>>


What on earth is a "range check" in C. There are no such, so of course
these non-existent checks do not cause Ada exceptions!

On the other hand, it certainly is nice if something like a zero divide
would raise and propagate the corresaponding exception if it corresponds
to a hardware trap. Of course if it does NOT correspond to a hardware
trap (e.g. numeric overflow on most machines), then of course C does not
check it, and of course there is no exception to catch.