The noerrexit NOERREXIT_UNTIL_EXEC bit is never set and can therefore be removed. In other words the patch only removes dead code.
I have been intrigued by the NOERREXIT_UNTIL_EXEC bit for a while. I didn't understand its purpose nor why the NOERREXIT_EXIT and NOERREXIT_RETURN bits wouldn't be enough to solve the problem at hand. After finally having a closer look, I must admit that I still don't understand. However, I discovered that the bit is never set and can safely be removed. More on that below.
The bit was introduced in
commit d6a32dd, where the noerrexit value 2 corresponds to today's NOERREXIT_UNTIL_EXEC and the value 1 to NOERREXIT_EXIT. There was no distinction yet between NOERREXIT_EXIT and NOERREXIT_RETURN. At that time, there was also no this_noerrexit variable. The distinction between NOERREXIT_EXIT and NOERREXIT_RETURN was introduced in
commit 97d4bdb, which also introduced today's noerrexit bits.
One thing that distinguishes the NOERREXIT_UNTIL_EXEC bit from the other noerrexit bits is that it seems intended for the caller(s) of the function that sets it, while the other bits are intended for the callee(s). This is similar to today's this_noerrexit variable. I wonder whether this bit was a first attempt at solving the problem that is solved in today's code by the this_noerrexit variable. This would explain why everything is still fine even though the bit is no longer set.
In today's code, the NOERREXIT_UNTIL_EXEC bit is only ever set in
loop.c at line 578. This line can only be reached if run != 0 && run !=2 && olderrexit == 0 && lastval == 0. The
loop above can only be exited at one of the following lines:
None of these cases lead to line 578. Thus the NOERREXIT_UNTIL_EXEC bit is never set and can safely be removed.
The code "noerrexit &= ~ (NOERREXIT_EXIT | NOERREXIT_RETURN)" at
line 580 can be simplified into "noerrexit = olderrexit" because NOERREXIT_UNTIL_EXEC was the only noerrexit bit that was flowing from callees to their caller.
Obviously all tests still pass. And I checked that the tests introduced by
commit d6a32dd are still present.
I have built this patch on top of my patch patch-06-fix-eval-and-source-statements.txt but I don't think that it depends on it nor on any of my previous patches (but I haven't tried to confirm it).
QUESTION: Should
NOERREXIT_SIGNAL's value be changed to 4 (from 8) since the value 4 is no longer used by NOERREXIT_UNTIL_EXEC?
Philippe