diff options
author | Martin Ågren <martin.agren@gmail.com> | 2018-10-30 09:09:37 +0100 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2018-10-31 10:22:44 +0900 |
commit | 71571cd7d61b2e5c90684322b38e60ffadd33448 (patch) | |
tree | 6b2849b79ce5afef2d740a73c9d810e4603f4d20 /fetch-pack.h | |
parent | Git 2.19.1 (diff) | |
download | tgif-71571cd7d61b2e5c90684322b38e60ffadd33448.tar.xz |
sequencer: break out of loop explicitly
It came up in review [1, 2] that this non-idiomatic loop is a bit tricky.
When we find a space, we set `len = i`, which gives us the answer we are
looking for, but which also breaks out of the loop.
It turns out that this loop can confuse compilers as well. My copy of
gcc 7.3.0 realizes that we are essentially evaluating `(len + 1) < len`
and warns that the behavior is undefined if `len` is `INT_MAX`. (Because
the assignment `len = i` is guaranteed to decrease `len`, such undefined
behavior is not actually possible.)
Rewrite the loop to a more idiomatic variant which doesn't muck with
`len` in the loop body. That should help compilers and human readers
figure out what is going on here. But do note that we need to update
`len` since it is not only used just after this loop (where we could
have used `i` directly), but also later in this function.
While at it, reduce the scope of `i`.
[1] https://public-inbox.org/git/CAPig+cQbG2s-LrAo9+7C7=dXifbWFJ3SzuNa-QePHDk7egK=jg@mail.gmail.com/
[2] https://public-inbox.org/git/CAPig+cRjU6niXpT2FrDWZ0x1HmGf1ojVZj3uk2qXEGe-S7i_HQ@mail.gmail.com/
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'fetch-pack.h')
0 files changed, 0 insertions, 0 deletions