Date:	Thu, 28 Nov 2002 08:03:29 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp-workers AT delorie DOT com
Subject:	Re: wctype.h: Why is wctrans_t a const unsigned char?
In-Reply-To:	<3DE5337A.5C29C45C@phekda.freeserve.co.uk>
Message-ID:	<Pine.SUN.3.91.1021128075536.22888C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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.

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.

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.

> 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).

- Raw text -