Re: [PATCH] strbuf_read_file(): preserve errno across close() call

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

Re: [PATCH] strbuf_read_file(): preserve errno across close() call

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,

Re: [PATCH] strbuf_read_file(): preserve errno across close() call

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) { >

Re: [PATCH] strbuf_read_file(): preserve errno across close() call

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

[PATCH] strbuf_read_file(): preserve errno across close() call

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