This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3.1] New functions pthread_[sg]etattr_default_np for default thread attributes
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 13 Jun 2013 15:54:49 +0000
- Subject: Re: [PATCH v3.1] New functions pthread_[sg]etattr_default_np for default thread attributes
- References: <CAAHN_R13bRF0UY_XZ7Rj6tSeSgq8c_0j4bbEH6m9BbGD32EycQ at mail dot gmail dot com> <20130528220730 dot 33C262C06F at topped-with-meat dot com> <20130529065138 dot GF2145 at spoyarek dot pnq dot redhat dot com> <20130529224222 dot 8A87F2C07E at topped-with-meat dot com> <20130606131212 dot GZ13968 at spoyarek dot pnq dot redhat dot com> <20130612000601 dot 54C9F2C06E at topped-with-meat dot com> <20130612101128 dot GB19582 at spoyarek dot pnq dot redhat dot com> <20130612231757 dot CCC752C07F at topped-with-meat dot com> <20130613022810 dot GJ19582 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1306131240490 dot 10141 at digraph dot polyomino dot org dot uk> <20130613130540 dot GV19582 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1306131419460 dot 8652 at digraph dot polyomino dot org dot uk> <51B9E053 dot 6050605 at redhat dot com>
On Thu, 13 Jun 2013, Carlos O'Donell wrote:
> Would you agree that the real problem is not that the message is
> printed to stderr, but that each test's stderr does not get
> recorded in a file for later review e.g. $test.err?
Putting stderr in $test.err wouldn't preserve the ordering between stdout
and stderr messages (test-skeleton.c makes stdout unbuffered, so for tests
using test-skeleton such an ordering would be present if both were
redirected to the same place).
> I think that the patch as Siddhesh has it is correct, but we need
> a testsuite fix to redirect stderr (along with a long list of other
> testsuite fixes).
>
> Unless you think that stderr should be used for another purpose,
> like actual testsuite problems?
I don't think there's a useful distinction between stdout and stderr in
testsuite output. I think the distinction should be between:
* Output that gives the status of a particular test assertion, preceded by
PASS, FAIL, UNSUPPORTED, UNRESOLVED etc.; ideally whether assertions pass
or fail should not affect the set of assertion names being reported on.
* Informational output saying more about how a particular function being
tested behaved, or otherwise indicating why the testcase described a
particular assertion as passing or failing.
I don't see a use in redirecting these to separate places. I suppose
test-skeleton should have printf-like functions that can be used for both
sorts of output, that generate unambiguous structured output as long as
tests avoid e.g. explicit newlines in the text passed to those functions.
(And obviously the above implies tests should be using test-skeleton
whenever possible, to get the standard functions for testcase output,
rather than ad hoc C code not using test-skeleton or ad hoc shell scripts
or makefile rules.)
--
Joseph S. Myers
joseph@codesourcery.com