From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a3235721 for ; Sun, 19 Jan 2020 17:11:50 +0000 (UTC) Received: (qmail 25897 invoked by uid 550); 19 Jan 2020 17:11:49 -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 25879 invoked from network); 19 Jan 2020 17:11:48 -0000 Date: Sun, 19 Jan 2020 20:11:37 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com In-Reply-To: <20200119161851.GC30412@brightrain.aerifal.cx> Message-ID: References: <20200119110743.GD2020@voyager> <20200119113134.GJ23985@port70.net> <8299f261-7870-57a6-37cf-d4ce482ad81e@openwall.com> <20200119161851.GC30412@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] Minor style patch to exit.c On Sun, 19 Jan 2020, Rich Felker wrote: > Conceptually the _start is an array; that means it's fine to iterate > over its elements, and we could even do so with the "correct" type. > The problem is that _end is a different symbol and thereby inherently > a "different object", and comparing against it with < is not valid; > the compiler can legitimately optimize that out. I think with != would > be valid, but I'm not sure we can trust compilers to honor any > consistency for such "one past the end" comparisons. Casting to > (uintptr_t) before doing the != comparison would absolutely be safe in > the abstract machine; whether compilers honor this is unclear (because > of the "provenance" stuff, which could break even the current code, so > arguably we should have some "provenance barrier" here). > > Of course exit runs the array in reverse, which makes it even more of > a mess. _end[-1] is clearly not valid when _end is an array object, > and the compiler is free to break that. I would suggest void (**ptr)(void); __asm__ ("" : "=g"(ptr) : "0"(..._end), "X"(..._start)); while (ptr != _start) (*--ptr)(); Alexander