Re: Locale-related questions

Hi, Morten W. Petersen : > need to hack a bit on terminal code This is not only about terminals but also about any other program or module which shall process your UTF-32 text. You would have to set up a complete UTF-32 capable system while everything around it expects UTF-8. For example, in C l

Re: Locale-related questions

Le decadi 20 frimaire, an CCXXIV, Morten W. Petersen a écrit : > Hm. But how would I go about setting up a locale that is in fact UTF-32? You do not. Locales are a bad API, do not use it except for the most basic tasks, and this is not a basic case. Regards, -- Nicolas George signature.as

Re: Locale-related questions

On Sun, Nov 29, 2015 at 4:04 PM, Nicolas George wrote: > Le nonidi 9 frimaire, an CCXXIV, Morten W. Petersen a écrit : > > I was looking for a locale that would enable me to putwchar a 32-bit > > Unicode character to stdout and have things handled correctly, > > automatically. Without any re-enc

Re: Locale-related questions

Le tridi 13 frimaire, an CCXXIV, to...@tuxteam.de a écrit : > Yeah, agreed, that's quote-worthy. Nicolas: can I put that into my > quotations book? With attribution, of course! No problem. I am flattered. Regards, -- Nicolas George signature.asc Description: Digital signature

Re: Locale-related questions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 03, 2015 at 03:25:38AM -0500, Neal P. Murphy wrote: > On Thu, 3 Dec 2015 09:01:40 +0100 > Nicolas George wrote: > > > (Sun is also responsible for making java's char type 16-bits and strings > > UTF-16. This is another case of headdesk, o

Re: Locale-related questions

On Thu, 3 Dec 2015 09:01:40 +0100 Nicolas George wrote: > (Sun is also responsible for making java's char type 16-bits and strings > UTF-16. This is another case of headdesk, or possibly headwall, although > entirely unrelated to the wchar_t issue. For those who do not know, > basically UTF-16 ma

Re: Locale-related questions

Le tridi 13 frimaire, an CCXXIV, Martin Str|mberg a écrit : > I understand the reference to (the mess from) MS (although at that > time everyone in America did think 64k would be enough characters for > everyone, didn't they?), but not the one to Sun. > > Were they the ones that made sure that C's

Re: Locale-related questions

In article Nicolas George wrote: > wchar_t portably. For starters, the i4s at microsoft decided that 64k > characters should be enough for everyone, so if your cross-platform includes > microsoftisms, you can not use wchar_t to represent an Unicode code point. > The i4s at sun had other interest

Re: Locale-related questions

Le nonidi 9 frimaire, an CCXXIV, Thomas Schmitt a écrit : > Well, in this case a byte does not necessarily consist of 8 bits, > which would make data exchange somewhat difficult. As I said, POSIX mandates that bytes are octets. C without POSIX does not allow reliable binary I/O. > But i confess t

Re: Locale-related questions

Hi, Nicolas George wrote: > # [#3] When applied to an operand that has type char, unsigned char, or > # signed char, (or a qualified version thereof) the result is 1. Well, in this case a byte does not necessarily consist of 8 bits, which would make data exchange somewhat difficult. But i confes

Re: Locale-related questions

Le nonidi 9 frimaire, an CCXXIV, Thomas Schmitt a écrit : > Are you sure this function qualifies for copyright at all ? ~:o) This would be for a judge to decide, if I were to sue. > The man page of putc(3) looks suspicious: >fputc() writes the character c, cast to an unsigned char, to str

Re: Locale-related questions

Hi, Nicolas George wrote: > void put_utf32be(FILE *f, unsigned c) > ... > Note: I hereby place this code under the terms of the GNU GPL. Are you sure this function qualifies for copyright at all ? ~:o) To be nitpicking ... The man page of putc(3) looks suspicious: fputc() writes the c

Re: Locale-related questions

Thomas already gave an answer with relevant points. Le nonidi 9 frimaire, an CCXXIV, Morten W. Petersen a écrit : > I'm writing an XML parser/writer/simple DOM, which will input and output > primarily in UTF-32. Is there a good or unavoidable reason to use UTF-32? This is really a bad choice of f

Re: Locale-related questions

Hi, Morten W. Petersen wrote: > This program outputs some information to stdout in the testing process, > and this is also UTF-32 As long as they are in stdout, the UTF-32 characters are byte sequences of no special meaning. The meaning as characters is attributed to them by the display program (

Re: Locale-related questions

Nicolas, OK. I don't know exactly what I'm talking about here as you can see. :) I'm writing an XML parser/writer/simple DOM, which will input and output primarily in UTF-32. This program outputs some information to stdout in the testing process, and this is also UTF-32 (internally a character

Re: Locale-related questions

Le nonidi 9 frimaire, an CCXXIV, Morten W. Petersen a écrit : > I was looking for a locale that would enable me to putwchar a 32-bit > Unicode character to stdout and have things handled correctly, > automatically. Without any re-encoding to UTF-8 and so on. I do not know what your program is abo

Re: Locale-related questions

Hi Alex, thanks for that. I was looking for a locale that would enable me to putwchar a 32-bit Unicode character to stdout and have things handled correctly, automatically. Without any re-encoding to UTF-8 and so on. -Morten On Sun, Nov 29, 2015 at 2:21 PM, Alex Vong wrote: > Hi Morten, > >

Re: Locale-related questions

Hi Morten, I have CCed this mail to . I think it is a good place to talk about your question. Regarding the question, could you please give more information? What problem are you facing? Are you trying to convert encoding from/to UTF-32 ? If yes, perhaps libiconv