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 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.