Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 29 Sep 2012 00:34:37 +0200
From: Daniel Cegiełka <>
Subject: Re: funopen() from BSD

2012/9/28 Rich Felker <>:

> A few general comments...
> 1. musl does not support 32-bit file offsets. All of the 32/64
> distinction stuff can be removed. off_t is always 64-bit.

I noticed, but I left it for sure. Already cleaned...

> 2. The original documentation states that the read/write functions can
> call setvbuf on the file to change its buffer. This imposes a huge
> restriction on the implementation that's not acceptable to musl. If
> that's part of the API, maybe we can look for some kind of workaround
> to block attempts to mess with the buffer, but it's hard since legal
> buffering changes (i.e. first action after open) should not be
> blocked.
> 3. flockfile/funlockfile are not musl functions, they're POSIX. Since
> funopen isn't part of plain ISO C, it's allowable to call them from
> funopen stuff, but it's going to impose unnecessary locking. The
> locking operations you want are FLOCK() and FUNLOCK() macros in
> stdio_impl.h.


And how to fix this piece of code:

	if ((fp = __sfp()) == NULL) return NULL;
	if ((c = (funcookie *)malloc(sizeof *c)) == NULL) {
		__sfp_lock_acquire ();
		fp->_flags = 0;		/* release */
#ifndef __SINGLE_THREAD__
		__lock_close_recursive (fp->_lock);
		__sfp_lock_release ();
		return NULL;

Did I find in musl some equivalent for these functions?
I'm sending a new (clean) version.


> I don't see any reason why funopen can't go in, but a little bit of
> motivation for why it's needed would be nice since it is mildly messy.
> Rich

View attachment "funopen.c" of type "text/x-csrc" (2691 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.