# Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c 3 messages from 2016-01-30 to 2016-01-31. Participants: Moritz Neeb, Junio C Hamano. Thread: https://gitlist.dev/t/41290 ## Moritz Neeb, 2016-01-30 14:30 Subject: Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c Message-ID: <56ACC916.8020008@moritzneeb.de> URL: https://gitlist.dev/e/56ACC916.8020008%40moritzneeb.de ``` Currently I am working on replacing strbuf_getline_lf() by strbuf_getline() in places where the input is trimmed immediately after reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf() callers", 2nd point. One instance I found was in wt-status.c. In read_rebase_todolist() the lines are read, checked for a comment_line_char and then trimmed. I wonder why the input is not trimmed before checking for this character? Is it safe to replace strbuf_getline_lf() by strbuf_getline() anyway? The only case I can imagine that could lead to unexpected behaviour then would be when someone sets the comment_line_char to CR. How likely is that? Why is the trim after checking for the comment char anyway? Should something like " # foobar" not be considered as comment? ``` ## Moritz Neeb, 2016-01-30 22:49 Subject: Re: Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c Message-ID: <56AD3DE9.2000004@moritzneeb.de> URL: https://gitlist.dev/e/56AD3DE9.2000004%40moritzneeb.de In-Reply-To: <56ACC916.8020008@moritzneeb.de> ``` On 01/30/2016 03:30 PM, Moritz Neeb wrote: > Currently I am working on replacing strbuf_getline_lf() by > strbuf_getline() in places where the input is trimmed immediately after > reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf() > callers", 2nd point. This thread turned obsolete, as I decided to post a patch to focus the discussion a bit more: http://thread.gmane.org/gmane.comp.version-control.git/285118 -Moritz ``` ## Junio C Hamano, 2016-01-31 16:59 Subject: Re: Replacing strbuf_getline_lf() by strbuf_getline() in wt-status.c Message-ID: URL: https://gitlist.dev/e/xmqqd1shy99w.fsf%40gitster.mtv.corp.google.com In-Reply-To: <56ACC916.8020008@moritzneeb.de> ``` Moritz Neeb writes: > Currently I am working on replacing strbuf_getline_lf() by > strbuf_getline() in places where the input is trimmed immediately after > reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf() > callers", 2nd point. > > One instance I found was in wt-status.c. In read_rebase_todolist() the > lines are read, checked for a comment_line_char and then trimmed. I > wonder why the input is not trimmed before checking for this character? > Is it safe to replace strbuf_getline_lf() by strbuf_getline() anyway? > > The only case I can imagine that could lead to unexpected behaviour then > would be when someone sets the comment_line_char to CR. How likely is that? > > Why is the trim after checking for the comment char anyway? Should > something like " # foobar" not be considered as comment? That is debatable, I would think, as "git commit" and others do not generally accept a line that does not begin with a comment char as a comment. I however think we made an exception for the rebase-i's insn file due to a mistake we made long time ago that allowed such line, caused people to build a workflow around the assumption that it is OK to prefix a comment line with whitespaces. Cf. the last paragraph of 1db168ee (rebase-i: loosen over-eager check_bad_cmd check, 2015-10-01). Cf. http://thread.gmane.org/gmane.comp.version-control.git/278841 So we probably want to be consistent with that in this codepath. ```