Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH] git-log: detect dup and fdopen failure

From: Jim Meyering <hidden>
Date: 2016-06-15 22:43:18

"Alex Riesen" [off-list ref] wrote:
On 6/27/07, Jim Meyering [off-list ref] wrote:
quoted
I didn't see that fdopen could fail with ENOMEM.
That'll teach me to trust the man page.  I see POSIX does mention it.
s/trust/use/ :)
I wouldn't trust Linux man pages nor POSIX, if I were you.
Ha.  Normally I don't rely solely on the man pages.
Check if this works in some exotic but common
environments (like MacOSX, Cygwin or HP-UX).
What do you mean?
I know that dup and fdopen work in those environments.
(And yes, they probably are broken, and no, you can't fix them,
and no, people are not going to stop using them).
quoted
+       if (!use_stdout) {
+               int fd = dup(1);
+               if (fd < 0 || (realstdout = fdopen(fd, "w")) == NULL)
+                       die("failed to duplicate standard output: %s",
+                           strerror(errno));
+       }
Kinda stuffed in here. What's wrong with plain
It's ok, but for the fact that when dup fails, all you get
is the uninformative EINVAL from fdopen.
 realstdout = fdopen(dup(1), "w");
 if (!realstdout)
   die("%s", strerror(errno));

(Yes, I do think that "duplicate standard output" is useless,
except for debugging. Exactly as strerror is, but that is shorter).
I like to include *something* in the diagnostic so that when someone
sees it and reports it developers have an easier time finding where it
comes from in the code.  Especially with something as unlikely (and hard
to reproduce) as this, that might be useful.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help