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

Erik Skultety eskultet at redhat.com
Tue Aug 28 12:30:23 UTC 2018


On Tue, Aug 28, 2018 at 02:24:42PM +0200, Ján Tomko wrote:
> 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.

Why? To see that glibc is new enough to support it? One would assume that if it
works for n (given your example I'm so sure it actually does...), it would work
for n+1 too, so I still don't see the point in this specific test case.

Thanks for the example though.
Erik




More information about the libvir-list mailing list