Re: Broken interactive rebase text after some UTF-8 characters
- From
- Michal Nowak <mnowak@startmail.com>
- Date
- Feb 1, 2019, 19:00 UTC
- Message-ID
- <7fe4edcd-f4ec-3ad5-a9ea-e4015e4afc37@startmail.com>
- In-Reply-To
- <xmqqpnsbzaa6.fsf@gitster-ct.c.googlers.com>
On 02/01/19 06:30 PM, Junio C Hamano wrote:
Show 60 quoted lines
> Michal Nowak <mnowak@startmail.com> writes:
>
>>> You already have that example. Just take the UTF-8 text in your original
>>> bug report, put it into something like
>>>
>>> int main(int argc, char **argv)
>>> {
>>> char utf8[] = "... your text here...";
>>>
>>> printf("%.*s", (int)(sizeof(utf8) - 1), utf8);
>>>
>>> return 0;
>>> }
>
> When replayed literally, this is not a very good test.
>
>> {global} newman@lenovo:~ $ cat printf.c
>> #include <stdio.h>
>> //#include <gettext.h>
>> int main(int argc, char **argv) {
>> char utf8[] = "Gergő Mihály Doma\n";
>> printf("%.*s", (int)(sizeof(utf8) - 1), utf8);
>> return 0;
>> }
>
> And this is replaying it literally.
>
> The current working suspicion in this thread is that the platform
> printf("%.*s", num, str) emits up to num "characters" starting at
> str, which is an incorrect implementation, as it should emit up to
> num "bytes".
>
> Notice that the num in this case is the byte count of that utf8[]
> string. That number is always larger than the number of "characters"
> for a string with multi-byte character(s) in it. Let's say that the
> sample string has N "characters", and it is N+X "bytes" long, where
> X > 1.
>
> If the suspicion is correct, i.e. the way the printf implementation
> is broken on this platform is that it shows up to num "characters",
> then the call is asking to show up to N+X "characters". The buggy
> printf shows all the available N "characters", notices the string
> stops there, and finishes. So you won't _see_ the bug with that
> test program.
>
> Instead, use something like this.
>
> #include <stdio.h>
>
> int main(int ac, char **av)
> {
> char utf8[] = "ふabc";
> printf("%.*s\n", 4, utf8);
> return 0;
> }
>
> With or without gettext or i18n, the output must end with 'a' followed
> by a newline, and you must not see 'b' nor 'c'. Otherwise your printf
> is broken.
> The output ends with 'a' for me on OpenIndiana:
{global} newman@lenovo:~ $ gcc tp.c -o tp && ./tp ふa
Though, I can reproduce the problem with Alban's test case the exact same way he wrote earlier today.
Michal