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

- Raw text -