Johannes Schindelin [off-list ref] writes:
quoted
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?
Hi Junio,
On Fri, 7 May 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
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).
There is really no need to introduce a `saved_errno` variable (which to me
would suggest that we need to save the current value of `errno` and
reinstate it later, as we do sometimes e.g. when we call `close()` after
noticing an error whose `errno` we need to preserve for the caller).
Ciao,
Dscho
On Tue, May 11, 2021 at 04:34:49PM +0200, Johannes Schindelin wrote:
On Fri, 7 May 2021, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
quoted
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