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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8955 invoked from network); 13 Apr 2022 22:58:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 22:58:59 -0000 Received: (qmail 24428 invoked by uid 550); 13 Apr 2022 22:58:56 -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 24396 invoked from network); 13 Apr 2022 22:58:55 -0000 Date: Wed, 13 Apr 2022 18:58:43 -0400 From: Rich Felker To: "Gary E. Miller" Cc: musl@lists.openwall.com Message-ID: <20220413225843.GY7074@brightrain.aerifal.cx> References: <20220412134355.59bd920e@spidey.rellim.com> <20220413142432.311e20f5@ncopa-desktop.lan> <20220413140532.GT7074@brightrain.aerifal.cx> <20220413103651.0087ca81@spidey.rellim.com> <20220413203835.GW7074@brightrain.aerifal.cx> <20220413141407.27cec2a1@spidey.rellim.com> <20220413222758.GX7074@brightrain.aerifal.cx> <20220413154314.006b6622@spidey.rellim.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220413154314.006b6622@spidey.rellim.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] *strerror_r() bug in musl On Wed, Apr 13, 2022 at 03:43:14PM -0700, Gary E. Miller wrote: > > > And yet, I'm supposed to check the GNU feature macros? So their > > > defines are good? But musl not having the equivalent is good? > > > > If you're using __GLIBC__ to work around an intentional glibc > > nonconformance issue, that's reasonable usage of it and part of the > > way they intend for you to be able to use it. > > So you intend for me to use __GLIBC__, for something I'm not sure > about, when __GLIBC__ is not part of your package or defined in your > doc? It's not part of our documentation because it has nothing to do with musl. As far as I can tell, you're only perceiving it as being "something about musl" because glibc is the frame of reference you're used to. > I'll stick to direct configure tests. > > > > Get your story straight please. > > > > I don't see where it's inconsistent. > > > > - Using standard macros provided by the implementation that describe > > interfaces available: good. > > Except, musl does not provide any? Or did I miss something? The macros from unistd.h declare conformance to the standards and which option groups are provided. There is a proposal for extending this system with information about extensions that aren't standardized, that was discussed on the libc-coord mailing list, but it never really moved forward. > On second thought, don't bother, I'll stick to direct configure tests. This is a choice I fully support.