Glenn Fowler wrote:
> On Tue, 15 Jan 2008 16:57:26 -0800 (PST) Don Cragun wrote:
> > Glenn & Roland,
> >       The C99 Standard (Subclause 7.11.2.1 "The localeconv function")
> > says that the character string pointed to by char *decimal_point and
> > char *thousands_sep in struct lconv contain "The decimal-point
> > character used to format nonmonetary quantities." and "The character
> > used to separate groups of digits before the decimal-point character in
> > formatted nonmonetary quantities.", respectively.   Note that in the C
> > Standard, "character" is a single-byte character.  Corresponding to
> > this, the POSIX standard in the description of Locale Definition file
> > (XBD Subclause 7.3.4 "LC_NUMERIC", P146, L4948-4949 & L4952-4954) we
> > have: "In contexts where standards limit the decimal_point to a single
> > byte, the result of specifying a multi-byte operand shall be
> > unspecified." and "In contexts where standards limit the thousands_sep
> > to a single byte, the result of specifying a multi-byte operand shall
> > be unspecified."
> >       So, in general, struct lconv char* elements are strings which
> > may contain zero or more characters before the terminating null, but
> > the decimal_point and thousands_sep fields aren't quite as free.
> 
> thanks Don
> so absent a standard multibyte interface ast/ksh will stick with
> the single byte characters provided by localeconv():
>         struct lconv *decimal_point
>         struct lconv *thousands_sep

But what happens when these data point to multibyte characters (see
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2008-January/005846.html
for an idea to split the arabic locales into one version which uses
ASCII characters and a 2nd version which uses the correct arabic
(multibyte) characters) ? AFAIK (Don may correct me) it's the author(s)
of the locale data which are responsible to define this correctly and
the "consumer side" (e.g. libast/ksh93) should just use the strings (and
not just the first byte) from struct lconv char* elements...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Reply via email to