From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2020 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: funopen() from BSD Date: Fri, 28 Sep 2012 17:35:01 -0400 Message-ID: <20120928213501.GI254@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1348868624 18722 80.91.229.3 (28 Sep 2012 21:43:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 21:43:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2021-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 28 23:43:49 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1THiLd-0002w4-Dh for gllmg-musl@plane.gmane.org; Fri, 28 Sep 2012 23:43:49 +0200 Original-Received: (qmail 16259 invoked by uid 550); 28 Sep 2012 21:43:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16251 invoked from network); 28 Sep 2012 21:43:44 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2020 Archived-At: On Fri, Sep 28, 2012 at 11:01:32PM +0200, Daniel Cegiełka wrote: > Hi, > > Rich wrote about files/threads locking. I'm trying to implement > functions funopen() and port it to musl. 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. 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. 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