Jeff King wrote:
> It's common to use error() to return from a function, like:
>
> if (open(...) < 0)
> return error("open failed");
>
> Unfortunately this may clobber the errno from the open()
> call. So we often end up with code like this:
>
> if (open(...) < 0) {
> int saved_errno = errno;
> error("open failed");
> errno = saved_errno;
> return -1;
> }
>
> which is less nice.
What the above doesn't explain is why the caller cares about errno.
Are they going to print another message with strerror(errno)? Or are
they going to consider some errors non-errors (like ENOENT when trying
to unlink a file), in which case why is printing a message to stderr
okay?
All that said, given that there are real examples of code already
doing this, the patch seems sane.
[...]
> usage.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html