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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 8FAD91F461 for ; Mon, 15 Jul 2019 14:50:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404848AbfGOOue (ORCPT ); Mon, 15 Jul 2019 10:50:34 -0400 Received: from cloud.peff.net ([104.130.231.41]:36500 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2404804AbfGOOqF (ORCPT ); Mon, 15 Jul 2019 10:46:05 -0400 Received: (qmail 21393 invoked by uid 109); 15 Jul 2019 14:46:05 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with SMTP; Mon, 15 Jul 2019 14:46:05 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 22815 invoked by uid 111); 15 Jul 2019 14:47:01 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.94) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) SMTP; Mon, 15 Jul 2019 10:47:01 -0400 Authentication-Results: peff.net; auth=none Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 15 Jul 2019 10:46:03 -0400 Date: Mon, 15 Jul 2019 10:46:03 -0400 From: Jeff King To: Johannes Sixt Cc: Carlo Arenas , Junio C Hamano , Ramsay Jones , Thomas Gummerer , GIT Mailing-list Subject: Re: [PATCH] range-diff: fix some 'hdr-check' and sparse warnings Message-ID: <20190715144602.GA26636@sigill.intra.peff.net> References: <41a60e60-d2c0-7d54-5456-e44d106548a4@kdbg.org> <20190714005129.GA4525@sigill.intra.peff.net> <54c2ee44-ee99-ea4a-3154-f642e0060877@kdbg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54c2ee44-ee99-ea4a-3154-f642e0060877@kdbg.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sun, Jul 14, 2019 at 10:30:27AM +0200, Johannes Sixt wrote: > Why would you re-order members? There's nothing wrong when a pointer is > initialized by 0. To appease tooling like "sparse" without having to remember to do anything specific at the point-of-use sites. I'm open to the idea that it is not worth appeasing sparse, but this may be a simple and practical compromise. > > But it does fall down > > when the first element _has_ to be a struct (like, say, any user of our > > hashmap.[ch] interface). > > No, it does not. It is not necessary to spell out nested structs in the > initializer. Ah, that is news to me. I know that this compiles OK with "gcc -Wall", but is it guaranteed by the standard? -- >8 -- #include struct outer { struct { int x; char *y; } inner; }; int main(void) { struct outer foo = { 0 }; printf("%d %p\n", foo.inner.x, foo.inner.y); return 0; } -- 8< -- If so, then I agree that "0" is a pretty good solution, tooling like "sparse" aside. I do agree with your sentiment that "0" can be read as "please zero-initialize this struct" and not really as an attempt to set an initial member pointer to zero. -Peff