public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
	Glibc hackers <libc-hacker@sources.redhat.com>
Subject: Re: [PATCH] Fix wide stdio
Date: Mon, 27 Nov 2006 14:05:00 -0000	[thread overview]
Message-ID: <20061127140506.GN3849@sunsite.mff.cuni.cz> (raw)
In-Reply-To: <45670D02.6010402@redhat.com>

On Fri, Nov 24, 2006 at 07:17:22AM -0800, Ulrich Drepper wrote:
> Jakub Jelinek wrote:
> >testcase from Arjan we attempt to munmap fp->_shortbuf (which is 
> >fortunately
> >not page aligned and thus the munmap just fails).
> 
> No.  We have this bug in the upstream BZ for some time and even had one 
> of the IBM people try to provide a patch.  It's not that easy.  The 
> current code is screwed up big time when it comes to wide streams and 
> setvbuf.  It's not such a trivial change.

I'd like to understand what's still screwed up big time after the patch
I posted.  For _IONBF I don't see what is broken, the _IO_UNBUFFERED
flag is set correctly in that case and _IO_buf_base is _shortbuf
while _wide_data->_IO_buf_base is _wide_data->_shortbuf (and _end
similarly).
In other cases things IMHO work just fine too, the only question is
what is the user passed buffer supposed to be used for in wide IO,
we need 2 kinds of buffers, one char buffer, one wchar_t buffer.
Currently the user buffer is used as the char buffer and uses a
default sized allocated buffer for the other cases.  I don't think
that violates POSIX, but if e.g. the user buffer is intentionally small,
then it might not be 100% what the user would expect.
Alternatives include (when not unbuffered, which is correctly handled
with the _shortbuf buffers):
- _IO_wide would allocate a wide (non-user) buffer with
  size in some correlation to the size of the narrow buffer
  (be it (_IO_buf_end - _IO_buf_base) * sizeof (wchar_t), or
  (_IO_buf_end - _IO_buf_base) / average_length_of_mb_char * sizeof (wchar_t),
  (_IO_buf_end - _IO_buf_base) or something similar
- use user provided buffer as the wide buffer (after aligning it if needed)
  and allocate a new narrow buffer, either with a size in some correlation
  to the wide buffer size or using default size
- split the user provided buffer into two regions, use one region for the
  wide buffer and the other region for the narrow buffer
It is certainly not obvious what the right behavior is and I think neither
of the 4 alternatives (including the current one) violates the standard.

I looked at BZ#2337.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2337#c4
lists several options to fix the bug as well:

Solution 1.) in there is basically the middle alternative above with default
size narrow buffer, but in itself isn't the right fix, as e.g. the wide
buffer can still be a user buffer, while narrow buffer default allocated
and so sharing the same _IO_USER_BUF bit for it is bad.

Solution 2a.), i.e. replace fp->_flags = _IO_MAGIC|CLOSED_FILEBUF_FLAGS;
in _IO_new_file_close_it with
fp->_flags = _IO_MAGIC|CLOSED_FILEBUF_FLAGS | (fp->_flags & _IO_USER_BUF);
is certainly possible, but only if we guarantee that at any time either
both narrow and wide buffers are malloced, or are alloced by user (resp.
_shortbuf).

Solution 2b.) which has a patch provided sounds very wrong, that just
means we will leak the narrow buffer.  wdefault_finish makes sense for
wstrops (where we don't use two kinds of buffers, just the wide one).

The patch I posted had two parts, one was the addition of
_IO_FLAGS2_USER_WBUF flag and using it wherever the wide buf was meant,
the other was doing _IO_setb (fp, NULL, NULL, 0) even for wide oriented
streams in _IO_new_file_close_it.  I believe the latter is a nicer
alternative to 2a.) above and then either we need the former (USER_WBUF
flag), or we need to guarantee both buffers have the same allocation
status (this would essentially require the "user user suplied buffer for
both narrow and wide buffers").

	Jakub

  reply	other threads:[~2006-11-27 14:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-24 13:05 Jakub Jelinek
2006-11-24 15:17 ` Ulrich Drepper
2006-11-27 14:05   ` Jakub Jelinek [this message]
2006-11-27 15:13     ` Ulrich Drepper
2006-12-08  9:53       ` Jakub Jelinek
2006-12-13 23:20         ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061127140506.GN3849@sunsite.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=arjan@linux.intel.com \
    --cc=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).