X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Fri, 16 Jun 2000 11:45:36 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject:	Re: Patch: sentinels for typedefs in headers
In-Reply-To:	<3949EEAF.E736F50B@softhome.net>
Message-ID:	<Pine.LNX.4.10.10006161136490.8899-100000@acp3bf>
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 Fri, 16 Jun 2000, Laurynas Biveinis wrote:

> Eli Zaretskii wrote:
> > This issue really is (will be) relevant in wgetc and other
> > wide-character I/O functions which we currently don't have.  If EOF is
> > not supposed to be converted into WEOF, then perhaps there's no
> > problem.
> 
> EOF is outside of normal character space, and WEOF is outside of
> wide char space. 

Careful, here. There are *two* things that might be callable 'wide char
space': the range of values in type wchar_t is one. The other is the
collection of all character codes used in 'extended character sets'
used by the locales supported by the compiler/library.

WEOF is not required to be outside the first, only outside the second,
i.e. the numeric value of WEOF may be between WCHAR_MIN and WCHAR_MAX.
There just may be no defined character in any character set that equals
WEOF.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -