delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/08/03:23:27

Date: Thu, 8 Feb 2001 10:21:35 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Stephen Silver <djgpp AT argentum DOT freeserve DOT co DOT uk>
cc: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: wctype.h and STLport
In-Reply-To: <003d01c09159$23527fe0$f9e4883e@oemcomputer>
Message-ID: <Pine.SUN.3.91.1010208102100.20284P-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, 7 Feb 2001, Stephen Silver wrote:

> > > Is there any objection to declaring these functions, even though
> > > DJGPP doesn't yet implement them?
> >
> > 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 ;-) I'd rather not do this just because STLport
says we should.

Can you describe what bad things happen if we don't add prototypes for 
those functions to the header?  Perhaps we could find a simpler solution 
for those adverse effects.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019