Re: [PATCH] trace2: refactor to avoid gcc warning under -O3

From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Denton Liu" <liu.denton@gmail.com>,
	"Jeff Hostetler" <jeffhost@microsoft.com>
Subject: Re: [PATCH] trace2: refactor to avoid gcc warning under -O3
Date: Wed, 12 May 2021 05:58:47 +0900	[thread overview]
Message-ID: <xmqqlf8lkmwo.fsf@gitster.g> (raw)
In-Reply-To: <YJrGOqjS10Z/WkE8@coredump.intra.peff.net> (Jeff King's message of "Tue, 11 May 2021 14:00:26 -0400")

Jeff King <peff@peff.net> writes:

> On Tue, May 11, 2021 at 04:34:49PM +0200, Johannes Schindelin wrote:
>
>> On Fri, 7 May 2021, Junio C Hamano wrote:
>> 
>> > 		/* 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.

Yes, that is what I tried to say (i.e. if the compiler does not know
errno has a defined value at certain places in our code and
complain, then "return errno ? errno : EIO" would get the same
warning because bases its outcome on the value of errno the compiler
thinks is possibly undefined at that point), but apparently I failed
to convey that clearly enough.

Thanks.