* [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
@ 2017-11-15 12:40 Phillip Wood
2017-11-16 5:29 ` Junio C Hamano
2017-11-17 22:06 ` Jeff King
0 siblings, 2 replies; 7+ messages in thread
From: Phillip Wood @ 2017-11-15 12:40 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, Phillip Wood
From: Phillip Wood <phillip.wood@dunelm.org.uk>
As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len)
!= len" pattern, 2017–09–13) the return value of write_in_full() is
either -1 or the requested number of bytes. As such comparing the
return value to an unsigned value such as strbuf.len will fail to
catch errors. Change the code to use the preferred '< 0' check.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index 903abf9533b188fd472c213c29a9f968eb90eb8b..d377161113009f394f118d81d27fa6117cde8e9f 100644
--- a/config.c
+++ b/config.c
@@ -2810,7 +2810,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
* multiple [branch "$name"] sections.
*/
if (copystr.len > 0) {
- if (write_in_full(out_fd, copystr.buf, copystr.len) != copystr.len) {
+ if (write_in_full(out_fd, copystr.buf, copystr.len) < 0) {
ret = write_error(get_lock_file_path(&lock));
goto out;
}
@@ -2872,7 +2872,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
* logic in the loop above.
*/
if (copystr.len > 0) {
- if (write_in_full(out_fd, copystr.buf, copystr.len) != copystr.len) {
+ if (write_in_full(out_fd, copystr.buf, copystr.len) < 0) {
ret = write_error(get_lock_file_path(&lock));
goto out;
}
--
2.15.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-15 12:40 [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern Phillip Wood
@ 2017-11-16 5:29 ` Junio C Hamano
2017-11-17 22:06 ` Jeff King
1 sibling, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2017-11-16 5:29 UTC (permalink / raw)
To: Phillip Wood; +Cc: Git Mailing List, Jeff King, Phillip Wood, Sahil Dua
Phillip Wood <phillip.wood@talktalk.net> writes:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len)
> != len" pattern, 2017–09–13) the return value of write_in_full() is
> either -1 or the requested number of bytes. As such comparing the
> return value to an unsigned value such as strbuf.len will fail to
> catch errors. Change the code to use the preferred '< 0' check.
Thanks, queued. This seems to have come from 9a5abfc7 ("After
renaming a section, print any trailing variable definitions",
2009-07-24), which is rather ancient, but was made worse by getting
duplicated by 52d59cc6 ("branch: add a --copy (-c) option to go with
--move (-m)", 2017-06-18) recently.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-15 12:40 [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern Phillip Wood
2017-11-16 5:29 ` Junio C Hamano
@ 2017-11-17 22:06 ` Jeff King
2017-11-18 10:20 ` René Scharfe
2017-11-18 11:27 ` Phillip Wood
1 sibling, 2 replies; 7+ messages in thread
From: Jeff King @ 2017-11-17 22:06 UTC (permalink / raw)
To: Phillip Wood; +Cc: Git Mailing List
On Wed, Nov 15, 2017 at 12:40:43PM +0000, Phillip Wood wrote:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len)
> != len" pattern, 2017–09–13) the return value of write_in_full() is
> either -1 or the requested number of bytes. As such comparing the
> return value to an unsigned value such as strbuf.len will fail to
> catch errors. Change the code to use the preferred '< 0' check.
Thanks for catching this. I wondered at first how I missed these obvious
cases, but the answer is that they were added after my commit. :)
There's one more case in write_section() that uses "==". That's not
actually wrong, but I wonder if we'd want to make it "< 0" for
consistency.
-Peff
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-17 22:06 ` Jeff King
@ 2017-11-18 10:20 ` René Scharfe
2017-11-18 17:52 ` Jeff King
2017-11-18 11:27 ` Phillip Wood
1 sibling, 1 reply; 7+ messages in thread
From: René Scharfe @ 2017-11-18 10:20 UTC (permalink / raw)
To: Jeff King, Phillip Wood; +Cc: Git Mailing List, Junio C Hamano
Am 17.11.2017 um 23:06 schrieb Jeff King:
> There's one more case in write_section() that uses "==". That's not
> actually wrong, but I wonder if we'd want to make it "< 0" for
> consistency.
Actually it *is* wrong.
-- >8 --
Subject: [PATCH] config: flip return value of write_section()
d9bd4cbb9cc (config: flip return value of store_write_*()) made
write_section() follow the convention of write(2) to return -1 on error
and the number of written bytes on success. 3b48045c6c7 (Merge branch
'sd/branch-copy') changed it back to returning 0 on error and 1 on
success, but left its callers still checking for negative values.
Let write_section() follow the convention of write(2) again to meet the
expectations of its callers.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 903abf9533..3f079c77ad 100644
--- a/config.c
+++ b/config.c
@@ -2315,7 +2315,7 @@ static ssize_t write_section(int fd, const char *key)
struct strbuf sb = store_create_section(key);
ssize_t ret;
- ret = write_in_full(fd, sb.buf, sb.len) == sb.len;
+ ret = write_in_full(fd, sb.buf, sb.len);
strbuf_release(&sb);
return ret;
--
2.15.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-17 22:06 ` Jeff King
2017-11-18 10:20 ` René Scharfe
@ 2017-11-18 11:27 ` Phillip Wood
1 sibling, 0 replies; 7+ messages in thread
From: Phillip Wood @ 2017-11-18 11:27 UTC (permalink / raw)
To: Jeff King, Phillip Wood; +Cc: Git Mailing List
On 17/11/17 22:06, Jeff King wrote:
> On Wed, Nov 15, 2017 at 12:40:43PM +0000, Phillip Wood wrote:
>
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len)
>> != len" pattern, 2017–09–13) the return value of write_in_full() is
>> either -1 or the requested number of bytes. As such comparing the
>> return value to an unsigned value such as strbuf.len will fail to
>> catch errors. Change the code to use the preferred '< 0' check.
>
> Thanks for catching this. I wondered at first how I missed these obvious
> cases, but the answer is that they were added after my commit. :)
>
> There's one more case in write_section() that uses "==". That's not
> actually wrong, but I wonder if we'd want to make it "< 0" for
> consistency.
Yes, I noticed that but didn't get round to looking at it properly the
other day. Rene's fix looks good to me.
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-18 10:20 ` René Scharfe
@ 2017-11-18 17:52 ` Jeff King
2017-11-18 20:25 ` René Scharfe
0 siblings, 1 reply; 7+ messages in thread
From: Jeff King @ 2017-11-18 17:52 UTC (permalink / raw)
To: René Scharfe; +Cc: Phillip Wood, Git Mailing List, Junio C Hamano
On Sat, Nov 18, 2017 at 11:20:04AM +0100, René Scharfe wrote:
> Am 17.11.2017 um 23:06 schrieb Jeff King:
> > There's one more case in write_section() that uses "==". That's not
> > actually wrong, but I wonder if we'd want to make it "< 0" for
> > consistency.
>
> Actually it *is* wrong.
Thanks for digging, I didn't look beyond that single line.
> -- >8 --
> Subject: [PATCH] config: flip return value of write_section()
>
> d9bd4cbb9cc (config: flip return value of store_write_*()) made
> write_section() follow the convention of write(2) to return -1 on error
> and the number of written bytes on success. 3b48045c6c7 (Merge branch
> 'sd/branch-copy') changed it back to returning 0 on error and 1 on
> success, but left its callers still checking for negative values.
>
> Let write_section() follow the convention of write(2) again to meet the
> expectations of its callers.
Yikes. It looks like this slipped by on the tests because we always
check "< 0" in the callers, not non-zero. So success would not look like
failure, but failure would look like success. And write failure does not
happen regularly in the test suite.
So this looks correct, and well-explained.
> Reported-by: Jeff King <peff@peff.net>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
I'm not sure I deserve a reported-by if I say "it looks fine" but am
totally wrong. ;)
-Peff
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern
2017-11-18 17:52 ` Jeff King
@ 2017-11-18 20:25 ` René Scharfe
0 siblings, 0 replies; 7+ messages in thread
From: René Scharfe @ 2017-11-18 20:25 UTC (permalink / raw)
To: Jeff King; +Cc: Phillip Wood, Git Mailing List, Junio C Hamano
Am 18.11.2017 um 18:52 schrieb Jeff King:
> On Sat, Nov 18, 2017 at 11:20:04AM +0100, René Scharfe wrote:
>> Reported-by: Jeff King <peff@peff.net>
>> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>
> I'm not sure I deserve a reported-by if I say "it looks fine" but am
> totally wrong. ;)
Right, wrong -- mere details. You pointed out that there was work
to do. :)
René
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-11-18 20:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-15 12:40 [PATCH] config: avoid "write_in_full(fd, buf, len) != len" pattern Phillip Wood
2017-11-16 5:29 ` Junio C Hamano
2017-11-17 22:06 ` Jeff King
2017-11-18 10:20 ` René Scharfe
2017-11-18 17:52 ` Jeff King
2017-11-18 20:25 ` René Scharfe
2017-11-18 11:27 ` Phillip Wood
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).