test-skeleton: redirect stderr to stdout

Rather than worry if we use funcs that dirty stderr instead of writing
to stdout, redirect stderr internally to stdout.  Now all output will
go to stdout regardless.
---
 test-skeleton.c | 4 ++++
 1 file changed, 4 insertions(+)

On Thu, Jun 16, 2016 at 12:48 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> +  fclose (stderr);
> +  dup2 (STDOUT_FILENO, STDERR_FILENO);
> +  stderr = fdopen (STDERR_FILENO, "w");

Wouldn't the dup2 be sufficient by itself?  And then you don't have to
worry about allocation failure in fdopen.

Also a setbuf(stderr, NULL) is probably appropriate.

zw

Zack Weinberg <zackw@panix.com> writes:

> On Thu, Jun 16, 2016 at 12:48 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> +  fclose (stderr);
>> +  dup2 (STDOUT_FILENO, STDERR_FILENO);
>> +  stderr = fdopen (STDERR_FILENO, "w");
>
> Wouldn't the dup2 be sufficient by itself?  And then you don't have to
> worry about allocation failure in fdopen.
>
> Also a setbuf(stderr, NULL) is probably appropriate.

Also, assigning stderr is a nono.

Andreas.

On 16 Jun 2016 08:50, Zack Weinberg wrote:
> On Thu, Jun 16, 2016 at 12:48 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > +  fclose (stderr);
> > +  dup2 (STDOUT_FILENO, STDERR_FILENO);
> > +  stderr = fdopen (STDERR_FILENO, "w");
> 
> Wouldn't the dup2 be sufficient by itself?  And then you don't have to
> worry about allocation failure in fdopen.

i don't think there's any guarantee of the stdio handles being sane when
the fd is changed underneath them.  if the standards say otherwise, or
we have a guarantee in glibc, then sure.

> Also a setbuf(stderr, NULL) is probably appropriate.

initially it's not needed [1], but since i'm recreating it, yeah, i'll
have to reset the buffer behavior.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/stderr.html
-mike

On 16 Jun 2016 14:56, Andreas Schwab wrote:
> Zack Weinberg writes:
> > On Thu, Jun 16, 2016 at 12:48 AM, Mike Frysinger wrote:
> >> +  fclose (stderr);
> >> +  dup2 (STDOUT_FILENO, STDERR_FILENO);
> >> +  stderr = fdopen (STDERR_FILENO, "w");
> >
> > Wouldn't the dup2 be sufficient by itself?  And then you don't have to
> > worry about allocation failure in fdopen.
> >
> > Also a setbuf(stderr, NULL) is probably appropriate.
> 
> Also, assigning stderr is a nono.

portability-wise, you are correct.  it works under glibc though.

the only other way to change one of these is to use freopen() and
that requires a FS path, and that's less portable to construct, and
less reliable to use (since FS perms are checked at open() time but
not at dup() time).
-mike

On Thu, Jun 16, 2016 at 11:07:06AM -0400, Mike Frysinger wrote:
> On 16 Jun 2016 08:50, Zack Weinberg wrote:
> > On Thu, Jun 16, 2016 at 12:48 AM, Mike Frysinger wrote:
> > > +  fclose (stderr);
> > > +  dup2 (STDOUT_FILENO, STDERR_FILENO);
> > > +  stderr = fdopen (STDERR_FILENO, "w");
> > 
> > Wouldn't the dup2 be sufficient by itself?  And then you don't have to
> > worry about allocation failure in fdopen.
> 
> i don't think there's any guarantee of the stdio handles being sane when
> the fd is changed underneath them.  if the standards say otherwise, or
> we have a guarantee in glibc, then sure.

The file behind fd might change but fd remains the same.
What kind of stdio insanity are you trying to avoid?