This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/10108] setvbuf _IOFBF doesn't honor size correctly
- From: "allachan at au1 dot ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 23 Jun 2014 02:02:59 +0000
- Subject: [Bug stdio/10108] setvbuf _IOFBF doesn't honor size correctly
- Auto-submitted: auto-generated
- References: <bug-10108-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=10108
--- Comment #9 from paxdiablo <allachan at au1 dot ibm.com> ---
I'm still not convinced that this should be considered a bug. The POSIX
standard and ISO C11 both state quite clearly (C11 has two extra words,
surrounded by [square brackets] below but the meaning is identical):
=====
If buf is not a null pointer, the array it points to MAY be used instead of a
buffer allocated by [the] setvbuf() [function] and the argument size specifies
the size of the array; otherwise, size MAY determine the size of a buffer
allocated by the setvbuf() function.
=====
Note the use of the word "may" (capitalised in my quote above). "May" and
"shall" have _very_ specific meanings in standards language, the former meaning
that something may or may not be true, the latter being that it's _required_ to
be true.
In other words, _nothing_ in POSIX or ISO (and the glibc manppage simply defers
to those standards) requires an implementation to use the buffer you pass in,
nor does it require an implementation to honor your size request.
The only way I can see this being an actual bug is if the return value is zero
even though the request is not being honoured. OP should modify their code as
per my previous comment to establish whether this is the case. However, even if
it is the case, simply returning an error would be the easiest fix :-)
--
You are receiving this mail because:
You are on the CC list for the bug.