On Mon, Apr 2, 2012 at 6:13 AM, Pete Wyckoff <pw@xxxxxxxx> wrote:
> jrnieder@xxxxxxxxx wrote on Sun, 01 Apr 2012 18:12 -0500:
>> Hi Pete,
>>
>> Pete Wyckoff wrote:
>>
>> > from :1M 100644 :103 hello.c
>> >
>> > It is missing a newline and should be:
>> >
>> > from :1
>> > M 100644 :103 hello.c
>>
>> Good idea; thanks.
>>
>> I agree that this at least deserves a warning and probably should
>> error out.
>>
>> [...]
>> > --- a/fast-import.c
>> > +++ b/fast-import.c
>> > @@ -2537,8 +2537,16 @@ static int parse_from(struct branch *b)
>> > hashcpy(b->branch_tree.versions[0].sha1, t);
>> > hashcpy(b->branch_tree.versions[1].sha1, t);
>> > } else if (*from == ':') {
>> > - uintmax_t idnum = strtoumax(from + 1, NULL, 10);
>> > - struct object_entry *oe = find_mark(idnum);
>> > + char *eptr;
>> > + uintmax_t idnum = strtoumax(from + 1, &eptr, 10);
>> > + struct object_entry *oe;
>> > + if (eptr) {
>> > + for (; *eptr && isspace(*eptr); eptr++) ;
>> > + if (*eptr)
>> > + die("Garbage after mark: %s",
>>
>> The implementation seems more complicated than it needs to be. Why
>> allow whitespace after the mark number?
>
> Fear of breaking existing fast-import users that might happen
> to have stray whitespace, or \r\n terminators.
>
> Other similar fast-import are less forgiving, such as
> parse_cat_blob. Maybe we should generalize and enforce its
> approach to parsing marks.
Docs say that "fast-import is very strict about its input", so
probably it is ok to both deny trailing spaces and fix all other
strtoumax()-es.
>
> -- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html