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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24754 invoked from network); 7 Jul 2023 15:46:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 15:46:08 -0000 Received: (qmail 13888 invoked by uid 550); 7 Jul 2023 15:46:06 -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 13856 invoked from network); 7 Jul 2023 15:46:05 -0000 Date: Fri, 7 Jul 2023 11:45:55 -0400 From: Rich Felker To: Alastair Houghton Cc: musl@lists.openwall.com Message-ID: <20230707154555.GG4163@brightrain.aerifal.cx> References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> <20230707124722.GE4163@brightrain.aerifal.cx> <054B1907-817E-496D-9F83-7FBE7AB0111A@apple.com> <829DB43D-E38A-4949-A0BE-B487279E4FC4@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <829DB43D-E38A-4949-A0BE-B487279E4FC4@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] __MUSL__ macro On Fri, Jul 07, 2023 at 04:34:37PM +0100, Alastair Houghton wrote: > On 7 Jul 2023, at 16:19, Markus Wichmann wrote: > > > > Yes, it makes people write worse code. Not making the macros available > > makes people write more portable code, which is a good thing. > > The people who would have misused the macros will simply find > another way to detect musl that you’ll like even less (look at the > Stack Overflow post we both mentioned; it’s literally the top > answer). The difference is whose fault it is, and who users blame, when they do. If we make a macro that says "you can now rely on implementation details of musl version x.y.z" and people do that, then it ceases to work in a future version, it's our fault, and people rightly blame us. If people do stupid hacks explicitly against our warnings, and against the specification for the interfaces they're using, and it breaks, it's clearly their fault. We have a really good history of being consistent on this, and as a result, of users and projects taking us seriously and making efforts to improve the overall ecosystem. Throwing that away would be really counterproductive. Rich