Message-ID: <003c01c091c9$951f89e0$fb4b893e@oemcomputer>
From: "Stephen Silver" <djgpp AT argentum DOT freeserve DOT co DOT uk>
To: "DJGPP Workers" <djgpp-workers AT delorie DOT com>
Subject: Re: wctype.h and STLport
Date: Thu, 8 Feb 2001 12:20:51 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> On Wed, 7 Feb 2001, Stephen Silver wrote:

> > > I'd rather not declare things we don't have.  If you want to
> > > *implement* them, go ahead,
> > 
> > Are we assuming that wchar_t represents a Unicode character?
> > If so, it may not be too difficult to generate the necessary
> > look-up tables from the data files at unicode.org.  But the
> > table for the isw*() functions would be 64K, and the tables
> > for towlower() and towupper() would be 128K each, so it would
> > increase the size of libc.a by over 50%.  (Maybe it's possible
> > to do better than that, but it's still going to be very large.)
>
> I suggest to back up a bit, before we turn a minor header update into
> a major libc rewrite ;-)

Yes, I wasn't really intending to do this.  I just wanted to clarify
what was involved in DJ's suggestion of implementing these functions.

> I'd rather not do this just because STLport says we should.

To be fair, the C and C++ standards also say we should.

> Can you describe what bad things happen if we don't add prototypes
> for those functions to the header?

It just means that STLport users can't #include <cwctype>, because
it will always give errors.

> Perhaps we could find a simpler solution for those adverse effects.

I don't think there is anything else that can be done in DJGPP
itself.  The DJGPP port of STLport could have a modified cwctype
to avoid the problem.

Stephen