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=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22608 invoked from network); 26 May 2023 17:21:00 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 May 2023 17:21:00 -0000 Received: (qmail 22151 invoked by uid 550); 26 May 2023 17:20:57 -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 22116 invoked from network); 26 May 2023 17:20:56 -0000 X-Virus-Scanned: SPAM Filter at disroot.org Date: Fri, 26 May 2023 23:20:37 +0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1685121644; bh=PQbVJBMvBSOMtIiJls8yv5XFuP5CSA8zCpI4sVs4s+Y=; h=Date:From:To:Subject:References:In-Reply-To; b=G06W+smHMZiT/v1dk6gea6pDn92x9kvAWIguDGxkgTntPJWXAa9R1veTMi9rMpx7P ue8yndbGdwPsEeSIZ4+b5H0UqYuE0GO+DtLJd6if+ezEJarrw+ELvB0PTd35YEe4NQ oWlw+65bYr+iCijX0Eyl/qC8sExwLXmpJeTamPm+J8445i+ocJNEm3vUtCz2Y1iW8W 77N1OUocVScA8SW4xith10PvlLqWzHDSjDUtdx76+Raq16yRCYHq4xrUk3G2F9zKMP 9rTJQ6o1VfpBSMHSY7obKACc15h8mDajZX+iDGpvgS5ajfKUn7PBdd46K03yhktv+U 4CEl971upTnew== From: NRK To: musl@lists.openwall.com Message-ID: <20230526172037.o2l4y63edb3k2n3n@gen2.localdomain> References: <26b68deb9fc65f8331c7fedaa6d807f4d973a4e6.1684932942.git.Jens.Gustedt@inria.fr> <3a4f4a8e-9179-6606-e449-6fc2812d3525@mulle-kybernetik.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a4f4a8e-9179-6606-e449-6fc2812d3525@mulle-kybernetik.com> Subject: Re: [musl] [C23 const 1/2] C23: change bsearch to a macro that respects the const contract On Fri, May 26, 2023 at 01:29:31PM +0200, Nat! wrote: > I think it's sort of obvious, that these macros increase code brittleness > due to now multiple execution of macro arguments vs. a single execution in a > function call. It would be heavily surprising if the controlling expression of _Generic was evaluated. Similar to `sizeof`, it only needs to know the type of the expression and thus doesn't require evaluation (only exception being VLAs in a sizeof). And looking at cppreference, it seems that the controlling expression indeed isn't evaluated: https://en.cppreference.com/w/c/language/generic#Notes | The controlling-expression and the expressions of the selections that | are not chosen are never evaluated. However, there is one thing that I don't quite understand about this patch: > + void const*: (void const*)bsearch((K), (void const*)(B), (N), (S), (C)), \ What's with the `(void const*)(B)` cast? It's already determined to be `void const *` via _Generic. - NRK