This is the mail archive of the libc-alpha@sourceware.org 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]

Re: Fix BZ #18757 (fmemopen doesn't fail with invalid modes)


On 09 Aug 2015 15:28, Paul Pluzhnikov wrote:
> +/* Check valid open mode.  Only "(r|w|a)\+?" are valid.  */

this is not what the documentation states:
https://www.gnu.org/software/libc/manual/html_node/String-Streams.html
	"The argument opentype is the same as in fopen"
https://www.gnu.org/software/libc/manual/html_node/Opening-Streams.html
	there are various GNU extensions here, and the standard 'b' flag

it's also not what POSIX requires:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
	it mentions the 'b' flag, and lists everything else as 'behavior 
	is undefined'

if you look at _IO_new_file_fopen in libio/fileops.c, you'll see the parsing
logic for mode is generally forgiving of unknown modes.  this is a good thing
as it means when glibc adds new extensions (like 'e'), you don't have to do a
version check at runtime before passing it in ... you can just do:
	fopen ("foo", "we");
for new versions, it does the right thing, and for old versions, it's ignored.

so the only thing we should check is whether the first byte is [rwa].  and it
seems to me that _IO_fopencookie (which fmemopen tails into) already does just
that for us.
-mike

Attachment: signature.asc
Description: Digital signature


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