Re: [PATH/RFC] parse-options: report invalid UTF-8 switches

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

 



Erik Faye-Lund <kusmabite@xxxxxxxxx> writes:

> But isn't UTF-8 constructed to be very unlikely to clash with existing
> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
> simply writes the byte as a hex-tuple?

If it's non-ascii and non-UTF-8, I think you'd want to display the byte
as it is, because this is how it was entered. IOW, I'd say we should
keep the current behavior in this case.

>> 2) The non-ascii sequence is NOT valid UTF-8, then if I read correctly
>>    (I didn't test) utf8_width would set next to NULL, and then you are
>>    in big trouble.
>
> Outch. Yeah, you are right; this is not good at all :)
>
> But I guess the solution above should fix this as well, no?

It should, yes.

Of course, there's still the case where the user entered "git -é" as a
à followed by a © in a latin-1 environment, but as you said, it's
unlikely enough ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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]