Re: Interfaces.C + generics: stack overflow

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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