2012/9/28 Rich Felker <dalias@aerifal.cx>:

> 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.

Corrected.

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);
#endif
		__sfp_lock_release ();
		return NULL;
	}

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

Daniel

> 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