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

From: Jim Meyering <jim@meyering.net>
Date: Jun 27, 2007, 13:32 UTC
Message-ID: <87d4zho74h.fsf@rho.meyering.net>
In-Reply-To: <81b0412b0706270618p850df2dy41b2b797d82e3276@mail.gmail.com>

"Alex Riesen" <raa.lkml@gmail.com> wrote:

> On 6/27/07, Jim Meyering <jim@meyering.net> 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.

Show 11 quoted lines

> (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.

Show 6 quoted lines

>  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.