Message-ID: <394936FA.392AAB79@softhome.net>
Date: Thu, 15 Jun 2000 22:05:14 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: Patch: sentinels for typedefs in headers
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000615113540 DOT 11632V-100000 AT is> <3948E86E DOT E28D1AE8 AT softhome DOT net> <200006151855 DOT VAA06521 AT mailgw1 DOT netvision DOT net DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> Don't look for WEOF, it indeed is not mentioned.  Instead, look at
> functions such as mbtowc, mblen, wctomb, etc.  You will see that all
> they do is to take a char and put it into a wchar_t, or the other way
> around.
> 
> In other words, out ``multibyte characters'' always have 1-byte
> length, and our ``wide characters'' are simply sign-extended ASCII
> characters.

Thanks for info.

> Now, imagine that a character is read from a file (via `getc', say),
> and then is passed through `mbtowc'.  What bothers me is this: what
> happens if `getc' returned EOF?  I don't have the standard handy, but
> isn't EOF supposed to be converted to WEOF?  If it is, we may have
> problem with mixing signed and unsigned.

Are you speaking about wide character support in C90 or its amendment in '94
and C99, or both? I'm using C99 draft with its rationale as my reference.
If I understand it correctly, putting int returned by getc() somewhere in
char[] to pass to mbtowc is not good idea. I don't think it should be
somehow specially handled - if binary represention of EOF happens to map
somewhere in multibyte char space, let it be. An analogy with single byte
chars - if you put EOF into string, you will get a perfectly valid 0xFF
char. I should be missing something here.

Laurynas