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

Re: [PATCH] utf8: handle systems that don't write BOM for UTF-16

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 11, 2019, 17:14 UTC
Message-ID
<xmqqk1i6i6xd.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20190210185523.GB28510@genre.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 19 quoted lines
> On Sun, Feb 10, 2019 at 08:04:13AM +0000, Torsten Bögershausen wrote:
>
>> I think we agree that Git will write UTF-16 always as big endian with BOM,
>> following the tradition of iconv/libiconv.
>> If yes, we can reduce the lines of code/#idefs somewhat, have the knob always on,
>> and reduce the maintenance burden a little bit, giving a simpler patch.
>
> No, I don't think it will. libiconv will always write big-endian, but
> glibc has a separate iconv implementation which writes the native
> endianness. (I believe FreeBSD's does the same thing as glibc's.) I
> think it's useful for us to know that we can handle UTF-16 using the
> system behavior where possible, since that's what the system is going to
> produce.
>
>> What do you think ?
>
> While I like the simplicity of the approach, as I mentioned above, and I
> did consider this originally, I'd rather test the behavior of the system
> we're operating on, provided it's suitable for our needs.
I see both sides of the argument, and each has its merit.

Let's go with the "follow the platform" and make sure the decision is documented somewhere in the resulting code.

Thanks, all.
Previous: brian m. carlsonNext: brian m. carlson
Message 18 of 30 in “t0028-working-tree-encoding.sh failing on musl based systems (Alpine Linux)”
  1. Kevin DaudtFeb 7, 2019
  2. brian m. carlsonFeb 8, 2019
  3. Rich FelkerFeb 8, 2019
  4. brian m. carlsonFeb 8, 2019
  5. Kevin DaudtFeb 8, 2019
  6. brian m. carlsonFeb 8, 2019
  7. Junio C HamanoFeb 8, 2019
  8. Kevin DaudtFeb 8, 2019
  9. brian m. carlsonFeb 8, 2019
  10. Junio C HamanoFeb 8, 2019
  11. brian m. carlsonFeb 9, 2019
  12. Kevin DaudtFeb 9, 2019
  13. utf8: handle systems that don't write BOM for UTF-16brian m. carlson, Feb 9, 2019
  14. Eric SunshineFeb 10, 2019
  15. brian m. carlsonFeb 10, 2019
  16. Torsten BögershausenFeb 10, 2019
  17. brian m. carlsonFeb 10, 2019
  18. Junio C HamanoFeb 11, 2019
  19. utf8: handle systems that don't write BOM for UTF-16brian m. carlson, Feb 11, 2019
  20. Eric SunshineFeb 11, 2019
  21. brian m. carlsonFeb 11, 2019
  22. utf8: handle systems that don't write BOM for UTF-16brian m. carlson, Feb 11, 2019
  23. Kevin DaudtFeb 11, 2019
  24. brian m. carlsonFeb 11, 2019
  25. Junio C HamanoFeb 12, 2019
  26. brian m. carlsonFeb 12, 2019
  27. Junio C HamanoFeb 12, 2019
  28. utf8: handle systems that don't write BOM for UTF-16brian m. carlson, Feb 12, 2019
  29. Rich FelkerFeb 8, 2019
  30. Torsten BögershausenFeb 9, 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.