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,4202c79b3ba60ee4
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Ada/X Windows Newbie Problem
Date: 1996/10/10
Message-ID: <dewar.844990272@merv>#1/1
X-Deja-AN: 188648485
references: <53g3e1$fj5@curlew.mtx.net.au> <JSA.96Oct10133355@alexandria>
organization: New York University
newsgroups: comp.lang.ada
Date: 1996-10-10T00:00:00+00:00
List-Id: <comp.lang.ada>


iJon asked

"I've noticed that GNAT (tries?) to raise Storage_Error in this sort of
case (bad pointer dereference attempt in imported code), though it is
not always successful.  Is this (the "catching" of the segv and
raising of SE) by design or accidental in some way?"

The only legitimate sigsegv that can occur is one caused by reference to
the stack guard page (in implementatoins where this occurs). This causes
storage error to be raised. There is some attempt to determine whether
the sigsegv is a result of a real storage error, but it is not always
successful.

All other cases of sigsegv's correspond to erroneous programs, and raising
storage error is of course a perfectly acceptable execution semantics for
an erroneous execution.