From: Fabian Stelzer <fs@gigacodes.de>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>,
Pedro Martelletto <pedro@yubico.com>, Jeff King <peff@peff.net>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2] gpg-interface: trim CR from ssh-keygen
Date: Wed, 5 Jan 2022 11:36:11 +0100 [thread overview]
Message-ID: <20220105103611.upfmcrudw6n3ymx6@fs> (raw)
In-Reply-To: <CAPig+cQinNZp_2=eo7nokMCZ9gc-tAKO1V_jejL2Ei9J63tSDQ@mail.gmail.com>
On 05.01.2022 02:09, Eric Sunshine wrote:
>On Tue, Jan 4, 2022 at 2:33 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Fabian Stelzer <fs@gigacodes.de> writes:
>> > I guess we need a bit more context for this patch to make sense:
>> >
>> > for (line = ssh_principals_out.buf; *line;
>> > line = strchrnul(line + 1, '\n')) {
>> > while (*line == '\n')
>> > line++;
>> > if (!*line)
>> > break;
>> >
>> > trust_size = strcspn(line, "\n"); /* truncate at LF */
>> > if (trust_size && trust_size != strlen(line) &&
>> > line[trust_size - 1] == '\r')
>> > trust_size--; /* the LF was part of CRLF at the end */
>> > principal = xmemdupz(line, trust_size);
>>
>> Ahh, OK. Sorry for being ultra lazy for not visiting the actual
>> source but just responding after reading only somebody else's
>> comments.
>
>I'm also guilty of being lazy and not consulting the actual source. Sorry.
>
>Fabian, thanks for all the extra context information.
>
>> OK, so I was completely missing the idea. And I agree that it may
>> be a good idea to check how strcspn() returned to deal with an
>> incomplete line, although as you hint later in the message I am
>> responding to, checking line[trust_size] would be a more obvious
>> implementation.
>>
>> In any case, I think the earlier part of the loop is more confusing,
>> and I think fixing that would naturally fix the trust_size
>> computation. For example, wouldn't this easier to grok?
>
>Indeed, the existing code is confusing me. I've been staring at it for
>several minutes and I think I'm still failing to understand the
>purpose of the +1 in the strchrnul() call. Perhaps I'm missing
>something obvious(?).
This whole loop was basically copied from parse_gpg_output() above. Without
the +1 this would always find the same line in the buffer. The +1 skips over
the previously found LF.
>
>> const char *next;
>>
>> for (line = ssh_principals_out.buf;
>> *line;
>> line = next) {
>> const char *end_of_text;
>>
>> /* Find the terminating LF */
>> next = end_of_text = strchrnul(line, '\n');
>>
>> /* Did we find a LF, and did we have CR before it? */
>> if (*end_of_text &&
>> line < end_of_text &&
>> end_of_text[-1] == '\r')
>> end_of_text--;
>
>It took several seconds for me to convince myself that the -1 array
>index was safe. Had the `line < end_of_text` condition been written
>`end_of_text > line`, I think it would have been immediately obvious,
>but it's subjective, of course.
>
>> /* Unless we hit NUL, skip over the LF we found */
>> if (*next)
>> next++;
>>
>> /* Not all lines are data. Skip empty ones */
>> if (line == end_of_text)
>> /*
>> * You may want to allow skipping more than just
>> * lines with 0-byte on them (e.g. comments?)
>> * depending on the format you are reading.
>> */
>> continue;
>>
>> /* We now know we have an non-empty line. Process it */
>> principal = xmemdupz(line, end_of_text - line);
>> ...
>> }
>>
>> The idea is to make sure that the place where the line ending
>> convention is taken care of is very isolated at the beginning of the
>> loop.
>
>Yes, this may be an improvement, though the cognitive load is still
>somewhat high. Using one of the `split` functions from strbuf.h or
>string-list.h might reduce the cognitive load significantly, even if
>this code still needs to handle CR removal manually since none of the
>`split` functions are LF/CRLF agnostic. (Adding such a function might
>be useful but could be outside the scope of this bug fix patch.)
How about something like this:
int string_find_line(char **line, size_t *len) {
const char *eol = NULL;
if (*len > 0) {
*line = *line + *len;
if (**line && **line == '\r')
(*line)++;
if (**line && **line == '\n')
(*line)++;
}
if (!**line)
return 0;
eol = strchrnul(*line, '\n');
/* Trim trailing CR from length */
if (eol > *line && eol[-1] == '\r')
eol--;
*len = eol - *line;
return 1;
}
Its use would then simply be:
char *line = strbuf.buf;
size_t len = 0;
while(string_find_line(&line,&len)) {
if (!len)
continue; /* Skip over empty lines */
principal = xmemdupz(line, len);
}
Not sure about the name though.
Maybe string_find_line() / _iterate_line / foreach_line ?
next prev parent reply other threads:[~2022-01-05 10:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 13:31 [PATCH] gpg-interface: trim CR from ssh-keygen -Y find-principals Johannes Schindelin via GitGitGadget
2021-12-03 14:18 ` Fabian Stelzer
2021-12-03 15:58 ` Jeff King
2021-12-04 13:11 ` Fabian Stelzer
2021-12-05 5:50 ` Junio C Hamano
[not found] ` <CABPYr=y+sDDko9zPxQTOM6Tz4E7CafH7hJc6oB1zv7XYA9KH1A@mail.gmail.com>
2021-12-09 16:33 ` Fabian Stelzer
[not found] ` <CABPYr=xfotWvTQK9k1eKHa0kP4SsB=TKKuM0d8cpMb5BtuUZLA@mail.gmail.com>
2021-12-09 17:20 ` Fabian Stelzer
2021-12-30 10:25 ` Fabian Stelzer
2021-12-05 23:06 ` Damien Miller
2021-12-06 8:39 ` Fabian Stelzer
2022-01-03 9:53 ` [PATCH v2] gpg-interface: trim CR from ssh-keygen Fabian Stelzer
2022-01-03 17:17 ` Eric Sunshine
2022-01-03 23:34 ` Junio C Hamano
2022-01-04 0:41 ` Eric Sunshine
2022-01-04 1:19 ` Junio C Hamano
2022-01-04 3:06 ` Eric Sunshine
2022-01-04 12:55 ` Fabian Stelzer
2022-01-04 19:33 ` Junio C Hamano
2022-01-05 7:09 ` Eric Sunshine
2022-01-05 10:36 ` Fabian Stelzer [this message]
2022-01-05 20:40 ` Junio C Hamano
2022-01-06 10:26 ` Fabian Stelzer
2022-01-06 17:50 ` Junio C Hamano
2022-01-09 20:49 ` Eric Sunshine
2022-01-10 12:28 ` Fabian Stelzer
2022-01-07 9:07 ` [PATCH v3] " Fabian Stelzer
2022-01-09 21:37 ` Eric Sunshine
2022-01-10 12:59 ` Fabian Stelzer
2022-01-10 17:51 ` Junio C Hamano
2022-01-10 17:03 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220105103611.upfmcrudw6n3ymx6@fs \
--to=fs@gigacodes.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=pedro@yubico.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).