X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Fri, 16 Jun 2000 11:35:44 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: sentinels for typedefs in headers
In-Reply-To:	<200006160747.KAA21364@alpha.netvision.net.il>
Message-ID:	<Pine.LNX.4.10.10006161124360.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, 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 supposed to be converted to WEOF. At the very least, that's what
the conversion function, btowc(), is defined to do, by C99. Quoting
the draft:

       [#3] The btowc returns WEOF if c has the  value  EOF  or  if
       (unsigned  char)c  does  not  constitute  a valid (one-byte)
       multibyte character in the initial shift state.   Otherwise,
       it   returns   the  wide-character  representation  of  that
       character.

Summing up what I read in the (draft) C99 standard, WEOF behaves almost
exactly the same as EOF, with the only exception that it is not required
to be negative. And wint_t is for wchar_t what int is for unsigned char: a
datatype large enough to hold any wide character, plus WEOF. The
difference is that WEOF is allowed to be within the range of wchar_t, so
wchar_t and wint_t can be the same.
	
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -