> +static inline int strtost(char const *s, size_t *result, const char **end)
> +{
> + unsigned long u;
> + char *p;
> +
> + errno = 0;
Minor nit. If this is to be able to see the error condition from
strtoul(), I think it should be done after the "!isdigit()" test,
immediately before we make strtoul() call, to avoid clearing errno
unnecessarily.
> + /* negative values would be accepted by strtoul */
> + if (!isdigit(*s))
> + return -1;
> + u = strtoul(s, &p, 10);
> + if (errno || p == s)
> + return -1;
> +static int parse_hunk_header(const char *p,
> + size_t *old_count, size_t *new_count,
> + const char **end)
> +{
> + size_t o = 1, n = 1;
> +
> + if (!skip_prefix(p, "@@ -", &p) ||
> + strtost(p, NULL, &p) ||
> + /* The range is -<start>[,<count>], defaulting to count = 1 */
> + !(*p == ' ' || (*p == ',' && !strtost(p + 1, &o, &p))) ||
> + !skip_prefix(p, " +", &p) ||
> + strtost(p, NULL, &p) ||
> + /* The range is +<start>[,<count>], defaulting to count = 1 */
> + !(*p == ' ' || (*p == ',' && !strtost(p + 1, &n, &p))) ||
> + !skip_prefix(p, " @@", &p))
> + return -1;
> +
> + *old_count = o;
> + *new_count = n;
> + *end = p;
We care only about how long the hunk is, and do not care exactly
where in the preimage it sits. The code looks correct, but for such
a specialized "parser", the name of the function gives a false
impression that it does a lot more. Finding it only slightly
disturbing.
> + * This function finds the end of the line, replaces the newline character with
> + * a NUL, and returns the offset of the start of the next line.
> + *
> + * If no newline character was found, it returns the offset of the trailing NUL
> + * instead.
Pretty bog-standard "read each line" helper. I suspect we may want
to consolidate multiple copies we may have elsewhere after the dust
settles. Looking good.
> +static inline int find_next_line(const char *line, size_t size)
> +{
> + char *eol;
> +
> + eol = memchr(line, '\n', size);
> + if (!eol)
> + return size;
> +
> + *eol = '\0';
> +
> + return eol + 1 - line;
> +}
> +static int read_mbox(const char *path, struct string_list *list)
> +{
> + struct strbuf buf = STRBUF_INIT, contents = STRBUF_INIT;
> + struct strbuf long_subject = STRBUF_INIT;
> + struct patch_util *util = NULL;
> + enum {
> + MBOX_BEFORE_HEADER,
> + MBOX_IN_HEADER,
> + MBOX_IN_COMMIT_MESSAGE,
> + MBOX_AFTER_TRIPLE_DASH,
> + MBOX_IN_DIFF
> + } state = MBOX_BEFORE_HEADER;
> + char *line, *current_filename = NULL;
> + int len;
> + size_t size, old_count = 0, new_count = 0;
> + const char *author = NULL, *subject = NULL;
> +
> + if (!strcmp(path, "-")) {
> + if (strbuf_read(&contents, STDIN_FILENO, 0) < 0)
> + return error_errno(_("could not read stdin"));
> + } else if (strbuf_read_file(&contents, path, 0) < 0)
> + return error_errno(_("could not read '%s'"), path);
> +
> + line = contents.buf;
> + size = contents.len;
> + for (; size; size -= len, line += len) {
> + const char *p;
> +
> + len = find_next_line(line, size);
> +
> + if (state == MBOX_BEFORE_HEADER) {
> +parse_from_delimiter:
> + if (!skip_prefix(line, "From ", &p))
> + continue;
> +
> + if (util)
> + BUG("util already allocated");
OK. The only transition that brings us into _BEFORE_HEADER state
is from _IN_DIFF and we consume and clear the current util there
before the transition happens, so this BUG() will trigger only when
there is some programming error, not any data errors.
Good.
> + util = xcalloc(1, sizeof(*util));
> + if (get_oid_hex(p, &util->oid) < 0)
> + oidcpy(&util->oid, null_oid());
> + util->matching = -1;
> + author = subject = NULL;
> +
> + state = MBOX_IN_HEADER;
> + continue;
> + }
> +
> + if (starts_with(line, "diff --git ")) {
> + struct patch patch = { 0 };
> + struct strbuf root = STRBUF_INIT;
> + int linenr = 0;
> + int orig_len;
> +
> + state = MBOX_IN_DIFF;
> + old_count = new_count = 0;
> + strbuf_addch(&buf, '\n');
> + if (!util->diff_offset)
> + util->diff_offset = buf.len;
> +
> + orig_len = len;
> + /* `find_next_line()`'s replaced the LF with a NUL */
> + line[len - 1] = '\n';
Does this work correctly when the input ended with an incomplete
line that lacked the final LF? find_next_line() would have given
the size of the remaining input, and the byte at line[len-1] is the
last byte on the incomplete line that is not LF.
> + len = len > 1 && line[len - 2] == '\r' ?
> + error(_("cannot handle diff headers with "
> + "CR/LF line endings")) :
> + parse_git_diff_header(&root, &linenr, 1, line,
> + len, size, &patch);
Cute (in that it tries to use a single "len < 0" for all error
conditions) but moderately hard to follow.
> + if (len < 0) {
> + error(_("could not parse git header '%.*s'"),
> + orig_len, line);
> + release_patch(&patch);
> + free(util);
> + free(current_filename);
> + string_list_clear(list, 1);
> + strbuf_release(&buf);
> + strbuf_release(&contents);
> + strbuf_release(&long_subject);
> + return -1;
> + }
OK.
> + if (patch.old_name)
> + skip_prefix(patch.old_name, "a/",
> + (const char **)&patch.old_name);
> + if (patch.new_name)
> + skip_prefix(patch.new_name, "b/",
> + (const char **)&patch.new_name);
Do we only accept "-p1" patches? From time to time we seem to hear
on this list from folks in communities that do not use -p1 (aka a/
and b/) convention.
> + } else if (state == MBOX_IN_HEADER) {
> + if (!line[0]) {
OK. After seeing a block of header lines, the first empty line
signals the end of the headers and we transition into a new state.
> + state = MBOX_IN_COMMIT_MESSAGE;
As an in-body "From:" can have have another blank line or some
in-body header other than "From: " before it at the beginning of an
e-mail body, I do not think this is a good code structure. I would
have expected that the first blank line would transition us into a
new state (in-commit-messages state) without doing anything else and
in that state:
- Leading blank lines are skipped, and we will stay in the same state.
- From:, Subject:, Date:, etc. are interpreted as in-body headers,
and we will stay in the same state, expecting more in-body
headers,
- Everything else will bring us into "we are now really reading the
log" state (do not lose that line that made us transition into
the new state---that line is the first line of the body).
would happen.
> + } else if (state == MBOX_IN_COMMIT_MESSAGE) {
> + if (!line[0]) {
> + strbuf_addch(&buf, '\n');
> + } else if (strcmp(line, "---")) {
> + int tabs = 0;
> +
> + /* simulate tab expansion */
> + while (line[tabs] == '\t')
> + tabs++;
> + strbuf_addf(&buf, "%*s%s\n",
> + 4 + 8 * tabs, "", line + tabs);
I am not sure if special casing the empty line above is correct. I
am assuming that you are pretending as if you read an "git show -s"
output after applying that patch, but "git log" gives a 4-space
indent even for an empty line, I think. A quick sanity check
$ git show -s | cat -e
on the patch I am responding to tells me that it is the case.
I'll stop here, as I see Phillip saw the reading of "diff --git"
output well enough to notice that diff.suppressBlankEmpty is handled
correctly and I'd trust his review.
Thanks.
