From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3548 invoked from network); 8 Apr 2023 00:50:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Apr 2023 00:50:14 -0000 Received: (qmail 24170 invoked by uid 550); 8 Apr 2023 00:50:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24125 invoked from network); 8 Apr 2023 00:50:07 -0000 Date: Fri, 7 Apr 2023 20:49:55 -0400 From: Rich Felker To: John Scott Cc: musl@lists.openwall.com Message-ID: <20230408004954.GH4163@brightrain.aerifal.cx> References: <0e96cffef26b0a5b689e6d316211829f6ed1a1cf.camel@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e96cffef26b0a5b689e6d316211829f6ed1a1cf.camel@posteo.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] Expose the fopencookie() data types more generally On Fri, Mar 31, 2023 at 12:35:36AM +0000, John Scott wrote: > Hi, > > We're allowed to expose these data types in POSIX-conforming > applications since they're implementation-reserved, and I think it's > a good idea. My use case is that I want to check for fopencookie() > via dlsym() without defining _GNU_SOURCE, and having the definition > of cookie_io_functions_t would be helpful for its usage. > > You may pull the signed commit from https://git.sr.ht/~jscott/musl-libc or use the following patch > > From f5f6db0d02db40dde067a3ad0a7fbd74f6019dd4 Mon Sep 17 00:00:00 2001 > From: John Scott > Date: Thu, 30 Mar 2023 20:26:13 -0400 > Subject: [PATCH] Expose the fopencookie() data types more generally > > These data types end in _t and so can be exposed even when strict > POSIX conformance is sought. This might be useful for an application > that doesn't want other side effects of defining _GNU_SOURCE, but > which still wants to use fopencookie(). While strictly speaking this is true, the "*_t is reserved" rule is rather controversial, and probably not good to rely on without really good reason. Even if you are dynamically binding to a symbol for nonstandard functionality like this, you still should be explicitly requesting that you want declarations for its types/constants/whatever, or, in this case since the types are not even opaque but explictly defined (and have to be, because you have to be able to define functions with matching signatures), you can just ignore the typedefs and write out the type to avoid depending on declarations in the header. Rich