|
Message-ID: <CAPLrYETAny1acOdPc4SZi5HmYaDMUgBU+J4JE_1pek-3vrjPEg@mail.gmail.com>
Date: Sat, 29 Sep 2012 00:34:37 +0200
From: Daniel Cegiełka <daniel.cegielka@...il.com>
To: musl@...ts.openwall.com
Subject: Re: funopen() from BSD
2012/9/28 Rich Felker <dalias@...ifal.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
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.