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_DNSWL_NONE,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22475 invoked from network); 3 May 2023 14:44:02 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 14:44:02 -0000 Received: (qmail 13517 invoked by uid 550); 3 May 2023 14:43:59 -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 13482 invoked from network); 3 May 2023 14:43:58 -0000 Date: Wed, 3 May 2023 10:43:46 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230503144346.GX4163@brightrain.aerifal.cx> References: <20230501205037.29e42745@inria.fr> <20230501194121.GS4163@brightrain.aerifal.cx> <20230502085740.23ff20d5@inria.fr> <20230502155903.30bee099@inria.fr> <20230502232009.GT4163@brightrain.aerifal.cx> <20230503091340.4627057a@inria.fr> <20230503140620.GV4163@brightrain.aerifal.cx> <20230503162649.19e2e95b@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230503162649.19e2e95b@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] patches for C23 On Wed, May 03, 2023 at 04:26:49PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Wed, 3 May 2023 10:06:20 -0400 you (Rich Felker ) > wrote: > > > I'd rather just fix it in one place (the implementation-internal > > header) so we don't have to worry about it. > > I still don't understand which header that is supposed to be. See src/include/*.h. These headers so far mostly just declare additional __-prefixed versions of interfaces where needed, but some of them do additional things. For example, src/include/stdio.h does some additional things: - suppresses the complete definition of FILE, which conflicts with libc-internal use where we have a real structure not a gratuitous fake type for pre-c11 (and POSIX) conformance reasons. - replaces the stdin/out/err macros with ones that resolve directly to address-of the internal objects rather than pointer objects subject to copy relocations -- this makes internal codegen a lot more efficient for functions which implicitly use stdin/out. Some other things I eventually intend to do in src/include/*: - making memcpy expand to __builtin_memcpy if available, and similar for other string functions with builtins; the few places where that could be problem would need to #undef them. - making calls to some functions where the interposable call overhead is likely significant expand to direct calls to hidden aliases. - etc. Undefining macro definitions that are unsuitable for some reason to the implementation-internal code in libc is another perfectly good use for these. Rich