From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13220 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: internal header proposal Date: Sun, 9 Sep 2018 20:47:46 -0400 Message-ID: <20180910004746.GR1878@brightrain.aerifal.cx> References: <20180907172312.GO1878@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1536540356 13265 195.159.176.226 (10 Sep 2018 00:45:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Sep 2018 00:45:56 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13236-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 10 02:45:52 2018 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 1fzAKt-0003Nn-Tb for gllmg-musl@m.gmane.org; Mon, 10 Sep 2018 02:45:51 +0200 Original-Received: (qmail 27773 invoked by uid 550); 10 Sep 2018 00:48:00 -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 27753 invoked from network); 10 Sep 2018 00:48:00 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13220 Archived-At: On Mon, Sep 10, 2018 at 01:27:20AM +0300, Alexander Monakov wrote: > I've written the following response a couple of days ago (before seeing your > more recent follow-up), but it bounced due to disk space issues. > > On Fri, 7 Sep 2018, Rich Felker wrote: > > Option 1: The big fancy header wrapping > > This looks nice to me, except ... > > > If we > > wanted, at some point we could even #define the unprefixed names to > > remap to the prefixed ones, and only #undef them in the files that > > define them, so that everything automatically gets the namespace-safe, > > low-call-overhead names. > > .... for this: I have reservations about such #defines. Preprocessing Yes, me too. It's not something I want to do now ("at some point we could even...") and I think there are probably good reasons not to do it at all. On the other hand I would potentially like to #define memcpy, memset, etc. back to __builtin_* in string.h, just undefining them in their respective source files, because -ffreestanding is gratuitously pessimizing a lot of code using them. In some cases just using struct assignments would solve the problem, but not all. > works on a wrong level to have such redirections as general policy (e.g. > if redirections are done via function-like macros, their effect won't > apply when taking the address). It creates an unnecessary distraction I had object-like macros in mind; there's no need for them to be function-like. > for people inspecting generated asm ("hm, where did this __ prefix came > from?"), and I can imagine it causing problems for debugging (e.g. if > one wanted to breakpoint on strchrnul in libc built with LTO, they'd > be surprised to see their breakpoint didn't hit and they needed to > breakpoint on __strchrnul instead). Actually in this case it'd work because they're just aliases. > > Option 2: New namespaced.h header > > Just want to remark that internal/libc.h already hosts a few such > declarations, so it might make sense to either grow the kitchen sink > further or aim to dismantle it altogether. > > Thank you for writing this up! Yay, glad someone appreciates it! Sometimes I write up proposals or documentation of development direction and get no response, and sure it's nice to have them to look back to, but it's much nicer to have someone reading and responding. Rich