Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-14 Thread Jeff King
On Wed, Sep 13, 2017 at 02:09:27PM -0700, Jonathan Nieder wrote: > > We ask to write 41 bytes and make sure that the return value > > is at least 41. This is the same "dangerous" pattern that > > was fixed in the prior commit (wherein a negative return > > value is promoted to unsigned), though

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-13 Thread Jonathan Nieder
Hi, Jeff King wrote: > We ask to write 41 bytes and make sure that the return value > is at least 41. This is the same "dangerous" pattern that > was fixed in the prior commit (wherein a negative return > value is promoted to unsigned), though it is not dangerous > here because our "41" is a

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-13 Thread Jeff King
On Wed, Sep 13, 2017 at 02:02:32PM -0400, Jeff King wrote: > > Does read_in_full need a similar treatment? > > It might actually return fewer than the requested number of bytes, so it > can't just use "< 0" in the same way (nor be adapted to return 0 on > success). But I think it's still a bug

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-13 Thread Jeff King
On Wed, Sep 13, 2017 at 10:53:57AM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > We ask to write 41 bytes and make sure that the return value > > is at least 41. This is the same "dangerous" pattern that > > was fixed in the prior commit (wherein a negative return > > value is promoted

Re: [PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-13 Thread Jonathan Nieder
Jeff King wrote: > We ask to write 41 bytes and make sure that the return value > is at least 41. This is the same "dangerous" pattern that > was fixed in the prior commit (wherein a negative return > value is promoted to unsigned), though it is not dangerous > here because our "41" is a

[PATCH 2/7] get-tar-commit-id: check write_in_full() return against 0

2017-09-13 Thread Jeff King
We ask to write 41 bytes and make sure that the return value is at least 41. This is the same "dangerous" pattern that was fixed in the prior commit (wherein a negative return value is promoted to unsigned), though it is not dangerous here because our "41" is a constant, not an unsigned variable.