Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: ANSI draft interpretation questions
Message-ID: <11937@smoke.BRL.MIL>
Date: 12 Jan 90 20:15:54 GMT
References: <21623@mimsy.umd.edu> <11879@smoke.BRL.MIL> <21675@mimsy.umd.edu> <11897@smoke.BRL.MIL> <21690@mimsy.umd.edu> <11907@smoke.BRL.MIL> <15618@haddock.ima.isc.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <15618@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <11907@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>>Definitely some additional "slop space" must be provided, somehow.
>>[Either two or four bytes, depending on which page of the pANS is correct.]
>Hmm, is it really bytes?  Or (multibyte) characters?

Bytes.  While the format is treated as multibyte, the input is not, and
the distinction is relevant only for matching "ordinary" (literal)
multibytes in the format.  Input ceases as soon as the first non-matching
character is input, and only the DIFFERING and subsequent characters
remain unread.  Matching bytes within the multibyte span simply get lost.
(No, I don't like that behavior.)

>Suppose MB_LEN_MAX == 2 and that '@' is a two-byte character whose bytes are
>{0x84, 0x30}.  If I call scanf("@") and the input stream contains 0x84 0x31,
>does it push back one byte or two?  Would it make any difference if I wrote it
>as scanf("\x84\x30")?

The 0x84 input byte is consumed and just 0x31 gets pushed back in both cases.