[PATCH] xts5: Fix Xlib3/XOpenDisplay-10 by using an invalid TCP hostname

[Aaron Plattner]

On 05/01/2012 02:56 AM, Geoff Clare wrote:
> Aaron Plattner<aplattner at nvidia.com>  wrote, on 30 Apr 2012:
>>
>> XOpenDisplay-10 calls XOpenDisplay(NULL) and expects it to fail.  This is bogus;
>> in fact XOpenDisplay-5 asserts exactly the opposite.
>
> No, XOpenDisplay-10 does not call XOpenDisplay(NULL).  It calls it
> with the value of config.displayhost.  If this is NULL when you ran
> the test, then that is a configuration mistake on your test system.
>
> The test has used this strategy since it was first written in 1995.
> If there was a problem of the magnitude you claim, it would have been
> spotted and corrected many years ago.
>
>> Instead, check for TCP support and then use a TCP display string with a bogus
>> hostname.
>
> The changes make the assertion testable only on POSIX systems that
> support TCP.  It would be better just to change the test code to
> check that config.displayhost is not NULL (and call delete() with
> a suitable message if it is), so that the assertion remains testable
> on all systems.

D'oh, you're right.  The problem was that I was running the XOpenDisplay 
test by itself rather than via xts-run, which is not something one could 
do in 1995 (and arguably shouldn't be able to do today).  I'll send out 
a change to make it return UNTESTED or UNRESOLVED rather than FAIL in 
that case, along with a new test that tries "nowhere.invalid.:0" on 
POSIX + TCP systems.

Do you think delete() (with makes it UNRESOLVED) or untested() would be 
more appropriate?  Is there a description somewhere of when the various 
result codes should be used?

-- Aaron