This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] second try: Add call to_IO_setbuffer() in fmemopen() after calling _IO_fopencookie()


Sorry about the malformed ChangeLog.  I'll try again.

I've been working bugzilla

In summary, the default stream buffering (block) will allow a caller to
write more bytes to a stream than the buffer backing the stream (created
by fmemopen()) can hold.

An fflush() or fclose() does not overflow the backing buffer but the
extra data on the stream is lost.

As discussed in the bugzilla entry, this problem can be avoided by
changing the buffering on the stream or by setting the stream buffer
size to that of the backing buffer.

Alternatively, I've attached a patch that sets the buffer size on the
stream within the fmemopen() function if that is a more desirable
solution.  Personally I'm ambivalent but I'm not sure I like the idea of
changing implicit block buffering but in this case it may be justified.

Ryan S. Arnold <>
IBM Linux Technology Center
Linux on Power Toolchain
2006-04-17  Ryan S. Arnold  <>

	* libio/fmemopen.c (fmemopen): Call _IO_setbuffer() after calling
	_IO_fopencookie() to prevent stream from buffering more characters
	than 'buf' can hold.

--- glibc-2.4/libio/fmemopen.c	2006-04-17 15:07:24.000000000 -0500
+++ glibc-2.4-new/libio/fmemopen.c	2006-04-17 16:03:19.363798894 -0500
@@ -201,6 +201,7 @@
   cookie_io_functions_t iof;
   fmemopen_cookie_t *c;
+  _IO_FILE *fp;
   if (__builtin_expect (len == 0, 0))
@@ -253,5 +254,7 @@ = fmemopen_seek;
   iof.close = fmemopen_close;
-  return _IO_fopencookie (c, mode, iof);
+  if ((fp = _IO_fopencookie (c, mode, iof)))
+    _IO_setbuffer(fp, c->buffer, c->size );
+  return fp;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]