After
2d893dff4c (rev-parse --parseopt: allow [*=?!] in argument hints,
2015-07-14) updated the parser, a line in parseopts's input can start
with one of the flag characters and be erroneously parsed as a opt-spec
where the short name of the option is the flag character itself and the
long name is after the end of the string. This makes Git want to
allocate SIZE_MAX bytes of memory at this line:
o->long_name = xmemdupz(sb.buf + 2, s - sb.buf - 2);
Since s and sb.buf are equal the second argument is -2 (except unsigned)
and xmemdupz allocates len + 1 bytes, ie. -1 meaning SIZE_MAX.
Avoid this by checking whether a flag character was found in the zeroth
position.
Reported-by: Ingy dot Net <ingy@ingy.net>
Signed-off-by: Øystein Walle <oystwa@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
if (!s)
s = help;
+ if (s == sb.buf)
+ die(_("missing opt-spec before option flags"));
+
if (s - sb.buf == 1) /* short option only */
o->short_name = *sb.buf;
else if (sb.buf[1] != ',') /* long option only */
test_cmp expect actual
'
+test_expect_success 'test --parseopt invalid opt-spec' '
+ test_write_lines x -- "=, x" >spec &&
+ echo "fatal: missing opt-spec before option flags" >expect &&
+ test_must_fail git rev-parse --parseopt -- >out <spec 2>err &&
+ test_cmp expect err
+'
+
test_expect_success 'test --parseopt help output: multi-line blurb after empty line' '
sed -e "s/^|//" >spec <<-\EOF &&
|cmd [--some-option]