git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Broken interactive rebase text after some UTF-8 characters

From
MNMichal 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
Previous: Junio C HamanoNext: Alban Gruin
Message 14 of 16 in “Broken interactive rebase text after some UTF-8 characters”
  1. Michal NowakJan 15, 2019
  2. Phillip WoodJan 16, 2019
  3. Michal NowakJan 16, 2019
  4. Phillip WoodJan 17, 2019
  5. Alban GruinJan 31, 2019
  6. Phillip WoodJan 31, 2019
  7. Alban GruinJan 31, 2019
  8. Junio C HamanoJan 31, 2019
  9. Johannes SchindelinFeb 1, 2019
  10. Michal NowakFeb 1, 2019
  11. Johannes SchindelinFeb 1, 2019
  12. Michal NowakFeb 1, 2019
  13. Junio C HamanoFeb 1, 2019
  14. Michal NowakFeb 1, 2019
  15. Alban GruinFeb 1, 2019
  16. Alban GruinFeb 1, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.