Re: [PATCHv2] parse-options: report uncorrupted multi-byte options

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2013, 02:10 UTC
Message-ID: <7va9rajn99.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8BByNnEhhE3TieM_kOy65t75rmB45ZzjJJ8AtL2N4-UFA@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 15 quoted lines

> On Tue, Feb 12, 2013 at 6:13 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> Because our command-line parser considers only one byte at the time
>> for short-options, we incorrectly report only the first byte when
>> multi-byte input was provided. This makes user-erros slightly
>> awkward to diagnose for instance under UTF-8 locale and non-English
>> keyboard layouts.
>>
>> Make the reporting code report the whole argument-string when a
>> non-ASCII short-option is detected.
>
> Similar cases:
>
> config.c:git_default_core_config() assumes core.commentchar is ascii.
> We should catch and report non-ascii chars, or simply accept it as a
> string.

That one is just an uninterpreted byte. core.commentString might be a nice extension to the concept, but it is an entirely different category.

> builtin/update-index.c:cmd_update_index(): error("unknown switch
> '%c'", *ctx.opt);

This one is in the same category as this topic.

> builtin/apply.c:apply_one_fragment(): error(_("invalid start of line:
> '%c'"), first); where 'first' may be a part of utf-8 from a broken
> patch.

This is where the patch is expected to have either " ", "-" or "+", again, anything else is an uninterpreted byte. It is more like reporting the file we found an error in, whose filename is not encoded in UTF-8 to the user's terminal.