Message ID | 1466052483-27705-1-git-send-email-vapier@gentoo.org |
---|---|
State | Superseded |
Headers |
Received: (qmail 35571 invoked by alias); 16 Jun 2016 04:48:12 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 35555 invoked by uid 89); 16 Jun 2016 04:48:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=dirty X-HELO: smtp.gentoo.org From: Mike Frysinger <vapier@gentoo.org> To: libc-alpha@sourceware.org Subject: [PATCH] test-skeleton: redirect stderr to stdout Date: Thu, 16 Jun 2016 00:48:03 -0400 Message-Id: <1466052483-27705-1-git-send-email-vapier@gentoo.org> |
Commit Message
Mike Frysinger
June 16, 2016, 4:48 a.m. UTC
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(+)
Comments
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?
diff --git a/test-skeleton.c b/test-skeleton.c index a9ad4ab7e9c6..3ff55810f0ec 100644 --- a/test-skeleton.c +++ b/test-skeleton.c @@ -343,6 +343,10 @@ main (int argc, char *argv[]) setbuf (stdout, NULL); #endif + fclose (stderr); + dup2 (STDOUT_FILENO, STDERR_FILENO); + stderr = fdopen (STDERR_FILENO, "w"); + while ((opt = getopt_long (argc, argv, "+", options, NULL)) != -1) switch (opt) {