Date: Thu, 28 Nov 2002 08:03:29 +0200 (IST) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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).