Re: noreturn for liboctave error handler function pointers

[Daniel J Sebald]

I searched for NORETURN in my email threads and found this as the last 
entry, so I'll continue with this thread...

Ben has run across an issue at least associated with the OCTAVE_NORETURN 
definition in the case where the base class has a virtual function that 
jumps to an error (i.e., OCTAVE_NORETURN) but the derived classes do not 
go that path.  I'm wondering how necessary the OCTAVE_NORETURN 
clarification is.  Might there really only need to be one routine that 
doesn't return, i.e., prints a message and then jumps somewhere?

One question I have with the many new jumps in program flow is how 
dynamic data management is to be done.  If the error routine stops 
program flow and jumps somewhere else, is the stack unwound?  How about 
something like:

xyz *myfunc(args) {
  xyz *retval;

  retval = new xyz();

  // Do some stuff, and then find dimensions don't agree
  error_message_and_jump_somewhere("Dimension mismatch");

  return xyz;
}

If the programmer isn't careful, they could write something like the 
above for which the malloced memory (via new) is not yet kept track of 
globally.  Changing program flow would leak that memory.

Perhaps what is needed is to rewrite the global "new" and "delete" operator:

http://en.cppreference.com/w/cpp/memory/new/operator_new

so that the interpreter could keep track of all the dynamic memory that 
has been allocated between returns to the command line, or at least when 
it's a good point to clean up the "octave intra-command memory table". 
So the new "new" operator would do the allocation, but also keep a 
linked-list of pointers to the memory it has allocated.  The new 
"delete" would look to the linked list and remove the memory address 
before freeing the memory.  If there is an error that redirects program 
flow, then free everything in that table (and unwind the stack).  Any 
object that has been associated with another container during processing 
(e.g., stored in global variable table) would need to be removed from 
the "intra-command memory table" so that it isn't cleared if an error 
occurs.

Dan


On 01/01/2016 11:31 PM, Rik wrote:
> On 12/31/2015 02:40 PM, John W. Eaton wrote:
> > Rik:
> >
> > I agree that tagging the liboctave error handlers with "noreturn" is the
> > right thing to do, but in the past they did return (or at least the ones
> > we defined in Octave did return).
> >
> > I suppose it's possible that someone provided their own versions of these
> > functions if they were using liboctave in their own program that also
> > returned after printing a message.
> >
> > I guess as things are, liboctave functions can still work properly if the
> > function called through the liboctave_error_handler pointer returns
> > because that's the way things have always worked up until now.  But
> > things will break if we start modifying liboctave in the same way as we
> > have modified the libinterp sources.
> >
> > Should we care?  Maybe just document the change in NEWS?
>
> I imagine the number of people who have overridden the default error
> handling routines is vanishingly small.  But we can document it just in
> case.  I added this note to the NEWS file:
>
>   ** The default error handlers in liboctave have been updated to use
>      exceptions.  After displaying an error message they no longer return
>      control to the calling program.  The error handler function can be
>      customized through the global variables "current_liboctave_error_handler"
>      and "current_liboctave_error_with_id_handler".  If a programmer has
>      installed their own custom error handling routines when directly linking
>      with liboctave then these must be updated to throw an exception and
>      not return to the calling program.
>
> --Rik

--

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com