🚀 go-pugleaf

> 2) several files get flagged as a warning that a volatile funtion does
> return, which appears to be false.

Not quite false, but deserving of explanation:

libg++ does not (yet) use the experimental g++ exception handling
facilities (they are still too new: Too many things would have to be
redone if the EH features change). So the only exception strategy is
for error traps like Integer::error() to call the function pointed to
by lib_error_handler (see builtin.h). By default, this points to
default_two_arg_error_handler, which prints a message on stderr and
aborts. But it *can* be reset to do anything at all, and need not
abort execution. On the other hand, *some* (not all) error() member
functions are used in a way that preclude any kind of sensible
continuation even if error() returns. I mark these as `volatile',
since the compiler might as well act as if they cannot return: This is
defensible in that even if (*lib_error_handler) returns, things are
going so wrong that you are no worse off if the compiler generates
(usually faster) code assuming execution aborts.  The compiler
correctly warns about these.

Again, saner strategies will be employed when the C++ exception
handling situation stabilizes.

-Doug