Re: [libvirt] [PATCH v5 0/3] vsh: Introduce new API for printing tables
On 08/28/2018 10:11 AM, Daniel P. Berrangé wrote:
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
Cannot believe the effort/time on this...
The problem with bypassing on such platforms is how does one then know
those platforms get fixed so that the "skip" can be removed? Of course
seeing test failure is not good either.
There is no simple answer, we can try to code around this or we can
accept on certain platforms the specific test may fail for a specific
reason and move on.
In the long run, it's a format that what percentage of our users will
use? Is naming domains or "other" libvirt objects using emojis a real
world problem that we really care to ensure that the table lines up
properly? Maybe it's just best to determine that the name has one of
those and accept that calculations are going to be wrong. Maybe we just
decide if we see one in a name (e.g. a non normally printable or greater
than some charset value via 0xNNNN) that we "assume" or "assign" the
maximum width possible for each of those characters found and move on.
Maybe we should "Validate" that a name doesn't have those chars and if
it does fail to recognize using a new errno code we invent, "ENO🙊🙉🙈,
usage of emoticons as names or keys is not supportable".
John