On Fri, Feb 23, 2018 at 10:00:24PM +0100, René Scharfe wrote:
> How about adding a stealthy close_no_errno(), or do something like the
> following to get shorter and more readable code? (We could also keep
> a single close() call, but would then set errno even on success.)
> [...]
> @@ -391,7
Am 23.02.2018 um 23:17 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> +#define IGNORE_ERROR(expr) do { int e_ = errno; expr; errno = e_; } while
>> (0)
>
> The macro certainly is a cute idea, but ...
>
>> @@ -391,7 +393,7 @@ ssize_t strbuf_read(struct strbuf *sb, int fd,
René Scharfe writes:
> +#define IGNORE_ERROR(expr) do { int e_ = errno; expr; errno = e_; } while (0)
The macro certainly is a cute idea, but ...
> @@ -391,7 +393,7 @@ ssize_t strbuf_read(struct strbuf *sb, int fd, size_t
> hint)
>
> if (got < 0) {
>
Am 23.02.2018 um 08:00 schrieb Jeff King:
> On Fri, Feb 23, 2018 at 01:49:52AM -0500, Jeff King wrote:
> Subject: [PATCH] strbuf_read_file(): preserve errno across close() call
>
> If we encounter a read error, the user may want to report it
> by looking at errno. However, our c
notice that quite a few strbuf error paths may call strbuf_release(),
too. Technically free() may clobber errno, too. I don't know if it's
worth protecting against (IIRC POSIX is being amended to disallow this,
but I have no idea how common it is in existing platforms).
-- >8 --
Subject: [PATCH] st
5 matches
Mail list logo