From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22519 invoked by alias); 29 Oct 2014 18:43:45 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 22264 invoked by uid 48); 29 Oct 2014 18:43:40 -0000 From: "arjun.is at lostca dot se" To: glibc-bugs@sourceware.org Subject: [Bug stdio/17522] `fputws' errors out when writing wide characters to unbuffered stream Date: Wed, 29 Oct 2014 18:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: 2.21 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: arjun.is at lostca dot se X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg00122.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17522 --- Comment #3 from Arjun Shankar --- (In reply to Carlos O'Donell from comment #2) > This is a bug in tst-skeleton.c IMO, it should allocate a buffer large > enough for the test to succeed, but small enough that you still get output > as quickly as possible in the even of a crash. > > Thus tst-skeleton.c needs to be enhanced to allow the test to define the > size of the stdout buffer it needs and then that can be allocated and passed > to setvbuf? Reading the definitions of setvbuf [1] and fputws [2] didn't make it clear to me that fputws is going to error out when writing a multi-byte character to an unbuffered stream. Andreas notes that there is a single byte buffer associated with unbuffered streams. Is this single byte buffer present in accordance with some contract offered by unbuffered streams? If not, then can I call the one byte buffer an implementation detail? If it is an implementation detail, would it make sense to associate each unbuffered stream with a buffer just wide enough to represent one wide character in the chosen encoding scheme, instead of just one byte? i.e. in the case of UTF-8, I guess this would mean a 4 byte buffer. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/setvbuf.html [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/fputws.html -- You are receiving this mail because: You are on the CC list for the bug.