"Alex Riesen" <raa.lkml@xxxxxxxxx> wrote:
> On 6/27/07, Jim Meyering <jim@xxxxxxxxxxxx> wrote:
>> 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).
>
>> + 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.
-
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
