From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11996 Path: news.gmane.org!.POSTED!not-for-mail From: Morten Welinder Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] stdio: implement fopencookie(3) Date: Tue, 10 Oct 2017 18:58:30 -0400 Message-ID: References: <20171010180356.11352-1-nenolod@dereferenced.org> <20171010205117.3deabfc7@inria.fr> <20171010205654.GJ1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1507676333 28416 195.159.176.226 (10 Oct 2017 22:58:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Oct 2017 22:58:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12009-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 11 00:58:44 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1e23Ty-0005PQ-6M for gllmg-musl@m.gmane.org; Wed, 11 Oct 2017 00:58:38 +0200 Original-Received: (qmail 23960 invoked by uid 550); 10 Oct 2017 22:58:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23942 invoked from network); 10 Oct 2017 22:58:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zX4fl9YfKhFXcjg934M4asaw2eR5cnF0jKixD7csBzM=; b=R+4AaW66e6roTGurTuwfxpcniiKVrwawhMh/JJaHq6TwGm5k0cklRXLjB7IuXTW4z9 CTmpSpX34H2BrlYeas7x/ApjYVkVwYbl0AvB2gj+jbONJnnN/lLtv5481+LqkghZKMIb l/elHqU97F5GW+JuioGBJqXiBrPNzzUVoszFAIZN3fF5DYrUaUTIK4DtJoSJ2//mHysm lvWWa3FaXRAY6ayy05WxkcQ39sbS6joFaDXqSK8/wBDQItYHx6Tt6Ne2PXrdNfyjqvao F7tfx1mmNwKCG4iNO+ENhhBGN26jVrD9bB9Q0ZPA8tKzXBW36GluMLzyIhEr0eQkImk1 f1hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zX4fl9YfKhFXcjg934M4asaw2eR5cnF0jKixD7csBzM=; b=XIrxHUxLvHug3OYBgf+zQR33i0wNQYCzZQ16CJoXeNc9SdI/83acfShCEqGJbkhofP nL9KGzehqjagCNYdgwR9giTxYr9bTBm6wjWLtV8U/oweesB+zRtPK2CesX7jbgYipKyB 9pWK5Aduh2Lk9huOYNHGAzafs6MIE23i7plSOdvp2MnaWoTqAfDfsGP2MrjI2imL3Uh6 dlcFTgPFM3F8WWoypQBoEAiTMvwmBVfw/QHUgoxLLFv4+Jsjg4N+8e6bEX7wcmbbCHux zYCvgu8jyJAJS/dXgUx+fcHH5TWefMyL2FPnI4xakPjwIw7pw8uUW9UpQQ2PElPpTXpV pcgA== X-Gm-Message-State: AMCzsaUsVRCmT73uhV7k6SR5DjJ1U12ttepp21xYFCbZHvV7b8CLGIZZ lmZklyTjHQt/5zyjeg9JEnUyYJ5NvXstQgC0DTdcOQ== X-Google-Smtp-Source: AOwi7QANPXLerJ18QG18kGrtLMO5h+DxmndngDeHx3LIEWZGPrvAagrixOih8OMyj+FXXR09Ityi1Rj/XZ333VUYwMQ= X-Received: by 10.46.18.85 with SMTP id t82mr27484lje.58.1507676311214; Tue, 10 Oct 2017 15:58:31 -0700 (PDT) In-Reply-To: <20171010205654.GJ1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11996 Archived-At: > Also note that while standard functions in POSIX can additionally be > defined as function-like macros, they can't be object-like macros, so > (*read), etc. are safe due to the parentheses. I'm not sure that's true. Solaris defines (or used to, at least), say, "open" to "open64" under the right conditions. With that, actual field names in the structure ends up being dependent on #include order. Quite a mess and worse for "stat" since "struct stat" gets renamed in addition to the function. "#define open my_table.my_open" would be fun too. I haven't seen that in the wild, though. M. On Tue, Oct 10, 2017 at 4:56 PM, Rich Felker wrote: > On Tue, Oct 10, 2017 at 08:51:17PM +0200, Jens Gustedt wrote: >> Hello William, >> >> On Tue, 10 Oct 2017 18:03:56 +0000 William Pitcock >> wrote: >> >> > The fopencookie(3) function allows the programmer to create a custom >> > stdio implementation, using four hook functions which operate on a >> > "cookie" data type. >> >> I know it is not your fault, but the naming conventions in this new >> interface are realy bad design. >> >> > +typedef struct { >> > + ssize_t (*read)(void *cookie, char *buf, size_t size); >> > + ssize_t (*write)(void *cookie, const char *buf, size_t size); >> > + int (*seek)(void *cookie, off_t *offset, int whence); >> > + int (*close)(void *cookie); >> > +} cookie_io_functions_t; >> >> > +FILE *fopencookie(void *cookie, const char *mode, cookie_io_functions_t io_funcs); >> >> The members may clash with macro names. E.g an implementation would be >> allowed to overload "close" with a macro. This is not possible if the >> implementation would want to use this interface here at the same time. >> >> User code could legitimately want to use a macro "seek" for its own >> purpose. >> >> Could you at least avoid to use user-space names as function >> parameters? Here you should just omit cookie, buf, size, offset, >> whence, mode and io_funcs. I think in musl parameters in prototypes >> usually don't have names. If you think that we should have them (they >> sort of document the interface) you should put them into a reserved >> namespace with leading underscore or so, or at least prefix them with >> cookie_ > > I agree with most of the principles here (esp. how bad the public > interface of this function is), but there's not a whole lot that can > be done. Your one request is reasonable and in fact mandatory for musl > header policy: we do not use parameter named at all in prototypes. So > it should read just: > > FILE *fopencookie(void *, const char *, cookie_io_functions_t); > > Also note that while standard functions in POSIX can additionally be > defined as function-like macros, they can't be object-like macros, so > (*read), etc. are safe due to the parentheses. > > Rich