Re: [PATCH v3.1] New functions pthread_[sg]etattr_default_np for default thread attributes

["Joseph S. Myers" <joseph at codesourcery 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