> On 16 Mar 2018, at 19:19, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>
> On Fri, Mar 16, 2018 at 1:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>>> However, I'm having a tough time imagining cases in which callers
>>> would want same_encoding() to return true if both arguments are NULL,
>>> but outright crash if only one is NULL (which is the behavior even
>>> before this patch). In other words, same_encoding() takes advantage of
>>> is_encoding_utf8() for its convenience, not for its NULL-handling.
>>> Given that view, the two explicit is_encoding_utf8() calls in
>>> same_encoding() seem redundant once the same_utf_encoding() call is
>>> added.
>>
>> So... does that mean we'd want something like this, or do you have
>> something else in mind?
>>
>> int same_encoding(const char *src, const char *dst)
>> {
>> static const char utf8[] = "UTF-8";
>>
>> if (!src)
>> src = utf8;
>> if (!dst)
>> dst = utf8;
>> if (same_utf_encoding(src, dst))
>> return 1;
>> return !strcasecmp(src, dst);
>> }
>
> I am not proposing anything like that for this patch or patch series.
> I'm merely asking why, after this patch, same_encoding() still
> contains the (in my mind) now-unneeded conditional:
>
> if (is_encoding_utf8(src) && is_encoding_utf8(dst))
> return 1;
My main motivation was to keep the existing behavior "as-is"
to avoid any regressions.
However, I agree with your critic of the inconsistencies.
Therefore, I will use Junio's suggestion above as it makes
the intented behaivior clear.
Thanks,
Lars
