Re: Interfaces.C + generics: stack overflow

[Robert Eachus <rieachus@comcast.net>]

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.

It would be nice if there was a parameter which identified where in that particular compiler the Storage_Error came from.  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.  If the compiler had a collection of strings to be returned, there would be no need to allocate space for a string after the Storage_Error..