Re: Date era specifications in the standard

> On 24 Jan 2022, at 10:50, Geoff Clare via austin-group-l at The Open Group > wrote: > > Thorsten Glaser wrote, on 23 Jan 2022: >> >> I just saw “1 AD” (“anno domini”) in line 70246 of the >> current working draft, and I’d like to ask that date+era >> specifications do not use the

Re: Date era specifications in the standard

> On 23 Jan 2022, at 20:05, Thorsten Glaser via austin-group-l at The Open > Group wrote: > > I just saw “1 AD” (“anno domini”) in line 70246 of the > current working draft, and I’d like to ask that date+era > specifications do not use the abrahamistic designation (in > English, BC/AD)

Re: LC_CTYPE=UTF-8

> On 25 Jun 2020, at 15:19, Ingo Schwarze wrote: > > Hans Aberg wrote on Thu, Jun 25, 2020 at 10:15:03AM +0200: > >> MacOS sets as default LC_CTYPE=UTF-8, not appearing in the 'locale >> -a' list. Then some software interprets this as though the locale >> is C/POSIX, disregards the UTF-8

LC_CTYPE=UTF-8

MacOS sets as default LC_CTYPE=UTF-8, not appearing in the 'locale -a' list. Then some software interprets this as though the locale is C/POSIX, disregards the UTF-8 encoding, and converts all non-ASCII (high bit set) char's into octal escape sequences. What is the correct interpretation here?

Re: About issue 0001108 and abs(INT_MIN)

> On 19 Jul 2018, at 14:13, Joseph Myers wrote: > > On Thu, 19 Jul 2018, Joerg Schilling wrote: > >> Since the C++ people already think about making this to happen in ther next >> standard, it seems that the C compilers may do something similar in the >> future. > > The latest version of

Re: can [[:digit:]] match something other than 0123456789?

> On 17 May 2018, at 11:02, Joerg Schilling > <joerg.schill...@fokus.fraunhofer.de> wrote: > > Hans Åberg <haber...@telia.com> wrote: > >>>> |I asked a person who speaks japanese and he told me that >>>> | >>>> | "\u4e00\

Re: can [[:digit:]] match something other than 0123456789?

> On 16 May 2018, at 18:13, Hans Åberg <haber...@telia.com> wrote: > > >> On 16 May 2018, at 17:14, Steffen Nurpmeso <stef...@sdaoden.eu> wrote: >> >> Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote: >> |Steffen Nurpmeso &l

Re: can [[:digit:]] match something other than 0123456789?

ONE, PARENTHESIZED DIGIT ONE, DIGIT > ONE FULL STOP etc. All these are marked "No", and i think the > discussion concluded that they should not be taken into account > when converting strings to numbers. Hans Åberg surely knows > better than I. I am happier the less I know

Re: can [[:digit:]] match something other than 0123456789?

> On 16 May 2018, at 10:53, Joerg Schilling > <joerg.schill...@fokus.fraunhofer.de> wrote: > > Hans Åberg <haber...@telia.com> wrote: > >> >>> On 16 May 2018, at 10:29, Joerg Schilling >>> <joerg.schill...@fokus.fraunhofer.de&

Re: can [[:digit:]] match something other than 0123456789?

> On 16 May 2018, at 10:29, Joerg Schilling > wrote: > > Robert Elz wrote: > >> How does one specify a locale for some area using Latin as its >> language, where I V X L C D M are the digits ? > > how do you like to specify a

Re: UTF-8 locale & POSIX text model

> On 27 Nov 2017, at 22:51, Chet Ramey <chet.ra...@case.edu> wrote: > > On 11/27/17 1:12 PM, Hans Åberg wrote: > >>>> On MacOS 10.13, one can set locale environment variables. The Terminal >>>> default login shell reads .profile; xterm reads .bash

Re: UTF-8 locale & POSIX text model

> On 27 Nov 2017, at 22:04, Chet Ramey <chet.ra...@case.edu> wrote: > > On 11/27/17 12:51 PM, Hans Åberg wrote: > >> On MacOS 10.13, one can set locale environment variables. The Terminal >> default login shell reads .profile; xterm reads .bashrc. There are oth

Re: UTF-8 locale & POSIX text model

> On 27 Nov 2017, at 19:35, Chet Ramey <chet.ra...@case.edu> wrote: > > On 11/27/17 1:19 AM, Hans Åberg wrote: > >>>> The deprecated HFS uses UTF-16, but MacOS has LC_CTYPE=UTF-8; thus with no >>>> additional qualifications like in LC_CTYPE=en_US.UT

Re: UTF-8 locale & POSIX text model

> On 27 Nov 2017, at 10:43, Stephane Chazelas <stephane.chaze...@gmail.com> > wrote: > > 2017-11-26 22:40:45 +0100, Hans Åberg: > [...] >> The deprecated HFS uses UTF-16, but MacOS has LC_CTYPE=UTF-8; >> thus with no additional qualifications like in

Re: UTF-8 locale & POSIX text model

> On 27 Nov 2017, at 03:16, Chet Ramey <chet.ra...@case.edu> wrote: > > On 11/26/17 1:40 PM, Hans Åberg wrote: > >> The deprecated HFS uses UTF-16, but MacOS has LC_CTYPE=UTF-8; thus with no >> additional qualifications like in LC_CTYPE=en_US.UTF-8. It wo

Re: UTF-8 locale & POSIX text model

> On 26 Nov 2017, at 13:43, k...@keldix.com wrote: > > Well, the pathname processing should be a function of the filesystem. Eg if > you have a windows > filesystem, or an apple filesystem mounted on a linux operating system, then > the file names > of the foreign system should be interpreted

Re: UTF-8 locale & POSIX text model

> On 26 Nov 2017, at 13:43, k...@keldix.com wrote: > > I don't have windos nor apple systems, but they run utf-16 natively, and > recent > Windows 10 system have a full linux (ubuntu) subsystem. I could also see > problems > with utf-16 and posix, but at least apple should have solved that