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. > > > > 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. Well the idea is to prove that we get the column width calculation correct, even when the the glibc we have doesn't support these as printable characters 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
