[libvirt] [PATCH v5 0/3] vsh: Introduce new API for printing tables

[Ján Tomko]

On Tue, Aug 28, 2018 at 02:10:55PM +0200, Erik Skultety wrote:
>On Tue, Aug 28, 2018 at 11:35:02AM +0100, Daniel P. Berrangé wrote:
>> On Mon, Aug 27, 2018 at 05:50:22PM +0200, Simon Kobyda wrote:
>> > On Fri, 2018-08-24 at 12:10 +0200, Michal Privoznik wrote:
>> > > On 08/24/2018 11:36 AM, Daniel P. Berrangé wrote:
>> > > > On Fri, Aug 24, 2018 at 10:59:04AM +0200, Michal Privoznik wrote:
>> > > >
>> > > > But first fix the build failures :-)
>> > > >
>> > > > On CentOS / RHEL:
>> > > >
>> > > > https://travis-ci.org/libvirt/libvirt/jobs/420024141
>> > > >
>> > > >
>> > > >  4)
>> > > > testUnicode                                                       .
>> > > > ..
>> > > > Offset 30
>> > > > Expect [государство
>> > > > -----------------------------------------
>> > > >  1    fedora28              running
>> > > >  2    🙊🙉🙈rhel7.5🙆🙆🙅]
>> > > > Actual
>> > > > [
>> > > >                   государство
>> > > > -----------------------------------------------------------------
>> > > > ------------------------------------------------------------
>> > > >  1    fedora28
>> > > >                                              running
>> > > >  2    \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xffrhel7.5\xff\x
>> > > > ff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff]
>> > > >
>> > >
>> > > Okay, this is probably due to ancient gcc that's there (4.8.0) and is
>> > > supposed to be fixed by adding -finput-charset= onto gcc command
>> > > line.
>> > > Haven't tested it though.
>> >
>> > I tried but it didn't help. From what I understood, CentOS has problems
>> > with unicodes such as 🙊🙉🙈🙆🙆🙅. On that system, it can convert
>> > any of those characters to wchar_t successfully and properly, but when
>> > we pass that character to iswprint, it returns 0 (considers those wide
>> > characters nonprintable).
>>
>> On the plus side, it appears that when this problem hits, the code is
>> still correctly doing the column alignment taking account of these
>> unexpected escape sequences.
>>
>> So how about storing 2 sets of expected data for this test case.
>>

Two is not enough. My clang 5.0.1 produces a test that displays the
monkeys correctly, but does not count their width properly:

$ VIR_TEST_RANGE=4 VIR_TEST_DEBUG=1 ./run tests/vshtabletest
TEST: vshtabletest
 4) testUnicode                                                       ...
Offset 24
Expect [      государство
-----------------------------------------
 1    fedora28      ]
Actual [государство
-----------------------------------
 1    fedora28]
                                                                      ... FAILED
>> In the unit test then call iswprint() to figure out which of the
>> two expected data sets to compare against.
>
>How does it help us during runtime when someone uses such characters in a
>domain's name? It would still return a row consisting of escape sequences.

Not necessarily, see above.

>So
>what's the point of providing 2 sets of expected data for a test just so it can
>pass, rather than use unicode characters we know would pass and everything else
>is a platform limitation which is out of our hands.

I still see a benefit in having testUnicodeBasic that passes everywhere
(does it?), and conditionally running the monkey test on platforms where
iswprint returns the proper results.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180828/9ecfe756/attachment-0001.sig>