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 21134 invoked from network); 7 Jul 2023 14:08:00 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 14:08:00 -0000 Received: (qmail 7420 invoked by uid 550); 7 Jul 2023 14:07:58 -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 7388 invoked from network); 7 Jul 2023 14:07:57 -0000 Date: Fri, 7 Jul 2023 08:47:23 -0400 From: Rich Felker To: Alastair Houghton Cc: musl@lists.openwall.com Message-ID: <20230707124722.GE4163@brightrain.aerifal.cx> References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] __MUSL__ macro On Thu, Jul 06, 2023 at 11:48:04AM +0100, Alastair Houghton wrote: > Hi all, > > Before I start, I’m aware of > > > > but I *still* want to add __MUSL__ (see attached patch). > > Let me explain what we’re doing, why we want it and why we think > musl *should* have it. We’re trying to add support for musl to Swift > > and its attendant core > libraries, and there are a number of things about musl that > presently differ from other platforms/C libraries we support. > > Examples include the use of `union`s in `pthread_mutex_t` et al > (which means that we can’t write a C++ `constexpr` function that > returns one, even if all it does is return > `PTHREAD_MUTEX_INITIALIZER`), the fact that it doesn’t have the > `d_namlen` member of `struct dirent`, or the fact that `dladdr()` is > a no-op when statically linked. This has nothing to do with being on musl. This has to do with writing semantically incorrect code that does not meet the requirements of the specification. pthread_mutex_t is not a value type. It's an object. You cannot initialize a pthread_mutex_t in one context and copy/assign/return it to be used somewhere else as a value. Only the actual object initialized may be used. For example, it may even contain references to its own address. Whatever implementations you think this works on on probably to not have a contract to make it work; you're writing to something that you observed working on your system. And in that case, once you've read the relevant source, you need to hard-code the unsafe code to be used *only on that specific implementation and version of it*, not assume musl is the one doing something odd/different because you hack doesn't work here. Rich