kernel: close streams after internal exception

[fingolfin]

... then rethrow.

Otherwise we may end up with references to input/output stream objects on the stack that are invalid.

I am actually not sure why this worked so far w/o causing us crashes in various situations. I think I reasoned this through at some point in the distant past and convinced myself the code is fine as it is, but I don't see it anymore. In any case, even if for some reason it was OK after all, I feel it is better to explicitly deal with this.

Diffs best viewed with "ignore whitespace" turned on.

[ChrisJefferson]

If you are going to try/catch in these functions, I think you need to make all the variables volatile so they are compatible with longjmp/setjmp? (could do it selectively, but probably easiest to just do everything)

[fingolfin]

In most of the changes, register clobbering is no problem: if we longjmp (which may result in clobbered data) we go into the GAP_CATCH block, which in all but one cases in this PR access a single local variable input, which is > 32kb and thus never stored in a register ;-), and then we GAP_THROW so control flow leaves and anything after the GAP_CATCH block is irrelevant.

There is one exception: in FuncREAD_STREAM_LOOP the GAP_CATCH block only sets a local BOOL rethrow to TRUE and then proceeds. Interestingly GCC nagged me here into adding volatile to the context object, which is not really used afterwards? We do use input and output but those are too bigger for clobbering. That leaves oldPrintObjState which should get a volatile (but GCC did not complain about it.. sigh)

[fingolfin]

@ChrisJefferson thoughts?

[ChrisJefferson]

Is "large so never stored in a register" sufficient? This being C, my assumption is the compiler will mess up the code at high optimisation, just because it can?

[fingolfin]

My thoughts on this:

• GCC seems to be quite good about warning about whichever locals it might actually clobber, and I fixed the single warning for this
• currently if there is exception, we'll just end up with a crash anyway because we don't clean up the input/output stream pointers (which point to stack allocated variables which will be gone due to longjmping back over them).
• I'd be happy to add volatile to TypInputFile input etc. in this PR, out of paranoia

I hope we can then merge it so I can get rid of this pesky crash (which seems difficult to trigger in pure GAP but I can trigger it in GAP.jl because the runtime environment is slightly different there)

[fingolfin]

Adding volatile there unfortunately results in this:

src/streams.c:934:22: warning: passing 'volatile TypInputFile *' (aka 'volatile struct TypInputFile *') to parameter of type 'TypInputFile *' (aka 'struct TypInputFile *') discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]

Hrm