Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3DE63D07.F240FF1A@phekda.freeserve.co.uk>
Date: Thu, 28 Nov 2002 15:57:59 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: wctype.h: Why is wctrans_t a const unsigned char?
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1021128075536 DOT 22888C-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Wed, 27 Nov 2002, Richard Dawe wrote:
> 
> > Anyway, I was looking at implementing the wctype and wctrans functions.
> 
> Thanks.  Please consider discussing the design here.  The issue of wide
> character support is a huge one, and it's easy to try to come up with
> an ambitious design for which we'll never have enough resources.  For
> example, the glibc implementation is one direction which we should NOT
> choose, IMHO.

Er, I haven't actually got a design. I was just try to integrate Mark E.'s
wide-character work and code up the "easy" functions that are independent of
the meaning of wchar_t. I was going to look at the other stuff later. Has
anyone got any good bookmarks for web pages about wide-character support in
the standard C library and Unicode?

> Personally, I think an implementation that supports UTF-8 as the only
> multibyte encoding and 16-bit Unicode codepoints (only the BMP) as its
> internal wide character format is more than enough for DJGPP.

Yes, I agree.
 
> Btw, one feature that I sorely miss in DJGPP is the positional format
> specifiers in printf family (%$1 etc.).  It is required in gettext to be
> able to rearrange words in translated messages; right-to-left languages
> such as Arabic and Hebrew need that quite a lot.  Perhaps someone would
> like to work on that, it shouldn't be hard to implement.

I thought Juan Manuel Guerrero was looking at that. Maybe I've got my wires
crossed.
 
> > These
> > return wctype_t and wctrans_t values respectively, which are opaque types.
> > wctype_t is defined as an unsigned short.
> 
> IIRC, the unsigned short part was due to compatibility with Windows (via
> RSXNT).

OK, thanks.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]