From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 029591F910 for ; Sat, 12 Nov 2022 16:34:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234974AbiKLQeg (ORCPT ); Sat, 12 Nov 2022 11:34:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231768AbiKLQef (ORCPT ); Sat, 12 Nov 2022 11:34:35 -0500 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5BAD11A3C for ; Sat, 12 Nov 2022 08:34:32 -0800 (PST) Received: (qmail 5266 invoked by uid 109); 12 Nov 2022 16:34:32 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sat, 12 Nov 2022 16:34:32 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 21519 invoked by uid 111); 12 Nov 2022 16:34:31 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sat, 12 Nov 2022 11:34:31 -0500 Authentication-Results: peff.net; auth=none Date: Sat, 12 Nov 2022 11:34:31 -0500 From: Jeff King To: =?utf-8?B?UmVuw6k=?= Scharfe Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org, Junio C Hamano , Taylor Blau , =?utf-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZw==?= Danh , SZEDER =?utf-8?B?R8OhYm9y?= , =?utf-8?B?THVrw6HFoQ==?= Doktor , Johannes Schindelin Subject: Re: [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type Message-ID: References: <1cb1c033-0525-7e62-8c09-81019bf26060@redhat.com> <221105.861qqhxz0o.gmgdl@evledraar.gmail.com> <25776063-a672-fc65-bed3-1bc8536ab8b3@web.de> <221105.86o7tlvxh0.gmgdl@evledraar.gmail.com> <46ee3f92-943f-10d5-7ec5-c68f1ced87ce@web.de> <221106.86k048w2f4.gmgdl@evledraar.gmail.com> <36337a3f-6443-f272-09f0-7ddb3c20d7a4@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36337a3f-6443-f272-09f0-7ddb3c20d7a4@web.de> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sat, Nov 12, 2022 at 11:42:09AM +0100, René Scharfe wrote: > > E.g. we have plenty of code that assumes ASCII, instead of catering to > > EBCDIC, and assuming NULL is (void *)0, not (void *)123456 or whatever. > > NULL is defined as "0" or "(void *)0" by C99 6.3.2.3 Pointers paragraph > 3 and 7.17 Common definitions paragraph 3. I think he is alluding to the fact that while the standard requires that a "0" constant refers to a NULL pointer, the representation does not have to be all-bits-zero. So: char *foo = 0; is fine, but: char *foo; memset(foo, 0, sizeof(&foo)); is not. And we absolutely do the latter in our code base anyway, because it's convenient and unlikely to be a problem on practical platforms. And I think it has always been our attitude in this community to let engineering practicality trump strict adherence to the standard. But "practicality" there should be measuring the tradeoff of how useful something is versus how likely it is to bite us. In the case under discussion, my gut feeling agrees with you, though. I'm skeptical that equivalence of object and function pointers is all that useful in practice. And your mention of CHERI seems like a plausible way it could bite us. -Peff