This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 06/13/2013 11:54 AM, Joseph S. Myers wrote:
> 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).

Good point (assuming ordering matters).

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

OK.

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

OK.

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

Agreed.

I've adjusted the wiki:
http://sourceware.org/glibc/wiki/Testing/Testsuite

We'll try to follow the new recommendation from now on.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]