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

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