Jeff King <peff@xxxxxxxx> 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.
