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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Interfaces.C + generics: stack overflow
Date: Mon, 27 Mar 2017 09:21:16 +0200
Organization: Aioe.org NNTP Server
Message-ID: <obaehc$1jv8$1@gioia.aioe.org>
References: <ejhckeF1tg7U1@mid.individual.net>
 <ob1a1t$b3d$1@franka.jacob-sparre.dk> <ejkigvFlkjbU1@mid.individual.net>
 <ob453p$1dv6$1@gioia.aioe.org> <ejncfbF83u9U1@mid.individual.net>
 <ejng82F8rprU1@mid.individual.net>
 <39ada48a-1faf-49fd-a97d-8544269de8e7@googlegroups.com>
NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:46484
Date: 2017-03-27T09:21:16+02:00
List-Id: <comp.lang.ada>

On 27/03/2017 00:34, Robert Eachus wrote:
> On Saturday, March 25, 2017 at 11:21:41 AM UTC-4, hreba wrote:
>
>> It works finally, I just don't know the reason. All I did is take
>> Dmitrys suggestion, and move the package instantiation from the main
>> program to package Integ_Aux (that is where the function to be passed to
>> the C-library-integrator is defined.)
>
> I'm glad you found a solution. Dave Emery used to call Storage_Error
> a  parachute that opened on impact. (Think Roadrunner cartoons.) Things
> have gotten a lot better, and GNAT in particular tries to identify all
> cases where Storage_Error will always be raised (as warnings). But the
> real issue is that it is in general not possible to create a stack frame
> or allocate an object after an occurrence of Storage_Error.

I never got Storage_Error otherwise than in infinite recursion calls. 
The most frequent case lies outside Ada when interfacing C.

> It would be nice if there was a parameter which identified where in
> that particular compiler the Storage_Error came from.

Stack and local memory should be a part of the contract. E.g. "I don't 
raise Storage_Error when there is more than X storage elements free."

> Yes, Storage_Error
> is raised during execution, but the generated code or sometimes even the
> run-time library code has no clue you can use during debugging. I wonder
> how much could be done with Exception_Message.

Probably nothing because in most cases the information necessary is 
already lost.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de