[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Tue, Aug 28, 2018 at 04:10:53PM +0200, Erik Skultety wrote:
> On Tue, Aug 28, 2018 at 03:52:56PM +0200, Ján Tomko wrote:
> > On Tue, Aug 28, 2018 at 02:46:08PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Aug 28, 2018 at 03:41:26PM +0200, Ján Tomko wrote:
> > > > On Tue, Aug 28, 2018 at 02:24:19PM +0100, Daniel P. Berrangé wrote:
> > > > > 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:
> > > > > > > > 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:
> > > > >
> > > > > Is this a different bug though ? The issue with iswprint() is varying
> > > > > according to glibc version, not compiler version.
> > > > >
> > > >
> > > > The broken setup is:
> > > > sys-libs/glibc-2.25-r9
> > > > sys-devel/clang-5.0.1
> > > >
> > > > It works on:
> > > > sys-libs/glibc-2.26-r7
> > > > with either of:
> > > > sys-devel/clang-5.0.1
> > > > sys-devel/clang-6.0.1
> > > >
> > > > So yes, it is a glibc bug.
> > > > Depending on the version, either just wcwidth returns incorrect values
> > > > for the monkeys (my case) or iswprint considers them non-printable.
> > >
> > > It sounds like in your case we're genuinely broken in the virsh
> > > code, not merely tests broken.
> > >
> > > I wonder if we need extra logic in the virsh code to handle escaping
> > > for the cases where wcwidth is returning wrong data, so we still get
> > > column layout correct ?
> > >
> >
> > I don't think so.
> >
> > 1) wouldn't that involve reimplementing the wcwidth function?
> > 2) users crazy enough to use new unicode characters are welcome to
> >   upgrade to new glibc, or suffer through misaligned virsh tables.
> 
> I second that, I don't think that in this case it's any beneficial trying to
> fix glibc problems just to offer users a consistent experience, we're not
> gnulib, besides, we're talking about table alignment which has been broken
> for ages and we've already made a significant progress here. Additionally, as
> Jano has pointed out, if someone feels adventurous, that's fine, but it
> may come with certain limitations.

Ok, so we just need get the test to correctly skip on platforms where
we know it won't get right answers


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]