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

[Jeff King <peff@peff.net>]

On Tue, May 11, 2021 at 04:34:49PM +0200, Johannes Schindelin wrote:

> On Fri, 7 May 2021, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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