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@xxxxxx> 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
