Hi, El jue., 30 ene. 2020 a las 16:01, Johannes Schindelin (<Johannes.Schindelin@xxxxxx>) escribió: > > Hi Miriam, > > On Thu, 30 Jan 2020, Miriam R. wrote: > > > El jue., 30 ene. 2020 a las 14:46, Johannes Schindelin > > (<Johannes.Schindelin@xxxxxx>) escribió: > > > > > > On Tue, 28 Jan 2020, Miriam Rubio wrote: > > > > > > > + > > > > + return res < 0 ? -res : res; > > > > > > This is a change in behavior, though: previously we guaranteed that the > > > exit code is either 0 on success or 1 upon failure. I am not quite sure > > > that we want to change that behavior. > > > > I think this is because different error codes might enable a bisecting > > script calling the bisect command that uses this function to do > > different things depending on the exit status of the bisect command. > > Oops. I am _totally_ wrong on this. > > As you are changing a lot of `exit(<n>)` to `return -<n>` with the > intention to turn the value into an exit code only at the > `cmd_bisect__helper()` level, this is actually required a change. > > I am a bit uneasy about this, but I could not see any return values in > `bisect.c` other than 0 and -1, prior to this patch series. > > However, I would love to see this refactored into its own commit, more > toward the beginning of the patch series, with a very clean commit message > that describes that intention of being _the_ exit point from `bisect.c`. Ok. Noted > > Without this change, you simply cannot change the `exit(<n>);` calls in > `bisect.c` for any `<n>` other than 0 or 1. > > Sorry that it took me so long to wrap my head around this rather trivial > idea. Please, don't worry :) Thank you again! Best, Miriam. > > Ciao, > Dscho
