Re: [PATCH] utf8.c: print warning about disabled iconv

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi.

On Mon, Jun 08, 2015 at 09:16:16AM -0700, Junio C Hamano wrote:
> Max Kirillov <max@xxxxxxxxxx> writes:

>> This gives undesirable result that returned data or even
>> data written into repository is incorrect and user is not
>> aware about it.
> 
> I do not necessarily agree with that.  The user knows what
> s/he is doing, data written to or shown from the
> repository is correct as far as the user is concerned, and
> the user takes the full respoinsibility when compiling out
> certain features.

User, in theory, can be not the same person who builds, or
can be not aware that the case needs recoding. It actually
started when I compiled git without iconv support and got
about 10 failed tests, and only 2 of them mentioned i18n in
their name.

Compiling out other features is not exactly the same. If
user compiles out curl, for example, git will not be able to
push or fetch through http, but it is not going to pretend
to be working, it will fail visibly.

> I actually am OK if the user gets exactly the same warning between
> the two cases:
> 
>  - iconv failed to convert in the real reencode_string_len()
> 
>  - we compiled out iconv() and real conversion was asked.

Does 'exactly the same' mean the same text? Shouldn't it
describe the reason? I can see 2 possible failures in case
of real iconv: unknown or unsupported encoding and invalid
input. Wouldn't them better to be detailed in warning?

-- 
Max
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]