Currently
execif uses an or-assignment to set the NOERREXIT_EXIT and NOERREXIT_RETURN bits. Other places, like for example
execwhile, use a plain assignment. This looks wrong because if any other noerrexit bits are present, they would inadvertently be lost.
Currently there is only one other noerrexit bit that is ever set: NOERREXIT_SIGNAL. It is set in init.c
here and
here. In both cases it seems to only affect the execution of initialization scripts.
The fourth noerrexit bit NOERREXIT_UNTIL_EXEC is never used. For more details on this, see the discussion of my other patch that removes this bit.
Thus, in regular code, it's currently impossible to observe a difference between or-assignments and plain assignments. However, it's certainly possible to build examples with well placed sleep statements inside if and while conditions in initialization scripts such that a SIGINT triggers different behaviors depending on whether it's caught in the middle of an if condition or in the middle of a while condition, which sounds wrong. Furthermore, if new noerrexit bits are ever added, the current plain assignments would most likely become problematic.
For these reasons, I think it's best to systematically use or-assignments to set noerrexit bits (and and-assigments, like in "noerrexit &= ~NOERREXIT_RETURN" to remove them, which is already the case today). Restoring bits to their prior state, like in "noerrexit = olderrexit", should keep using plain assignments.
This patch is built on top of my patch patch-07-remove-noerrexit-until-exec.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).
Philippe