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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 58DC11F5AE for ; Tue, 11 May 2021 18:00:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231774AbhEKSBe (ORCPT ); Tue, 11 May 2021 14:01:34 -0400 Received: from cloud.peff.net ([104.130.231.41]:50864 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231437AbhEKSBe (ORCPT ); Tue, 11 May 2021 14:01:34 -0400 Received: (qmail 23877 invoked by uid 109); 11 May 2021 18:00:27 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 11 May 2021 18:00:27 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 26014 invoked by uid 111); 11 May 2021 18:00:27 -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; Tue, 11 May 2021 14:00:27 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 11 May 2021 14:00:26 -0400 From: Jeff King To: Johannes Schindelin Cc: Junio C Hamano , =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org, Denton Liu , Jeff Hostetler Subject: Re: [PATCH] trace2: refactor to avoid gcc warning under -O3 Message-ID: References: <20200404142131.GA679473@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, May 11, 2021 at 04:34:49PM +0200, Johannes Schindelin wrote: > On Fri, 7 May 2021, Junio C Hamano wrote: > > > Johannes Schindelin writes: > > > > >> Otherwise I'd strongly prefer to see a word that hints that this is > > >> an otherwise unneeded workaround for comiplers. Your suggested > > >> title instead hints that it is wrong to assume that errno will be > > >> set to non-zero after a syscall. I do not think that is the message > > >> we want to send to our readers. > > > > > > Right, the oneline I suggested was only for the original patch, with which > > > I disagreed. > > > > I actually do not know how your rewrite could be better, though. > > > > /* GCC thinks socket()/connect() might fail to set errno */ > > return errno ? errno : EIO; > > > > If a compiler thinks errno may *not* be set, can 'errno' be reliably > > used to decide if it can be returned as-is or a fallback value EIO > > should be used, without triggering the same (incorrect) working in > > the first place? > > Oh, I guess I mistook the problem for something else, then. > > If the problem is that `errno` is not set in case of failure, the > resolution is easy (and even recommended in the manual page of `errno`): > simply set it to 0 before the syscall (or in the function that relies on > `errno == 0` means success). I don't think that is the problem. According to the standard, errno is always set to a non-zero value after a syscall failure. The problem is only that the compiler does not incorporate that special knowledge of the variable, so it generates a warning even though we can reason that the situation it describes is impossible. -Peff