From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11097 Path: news.gmane.org!.POSTED!not-for-mail From: He X Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8' Date: Sat, 4 Mar 2017 16:02:58 +0800 Message-ID: References: <20170129163329.GL1533@brightrain.aerifal.cx> <20170208143147.GY1533@brightrain.aerifal.cx> <20170211023610.GA1520@brightrain.aerifal.cx> <20170212023422.GE1520@brightrain.aerifal.cx> <20170213132816.GG1520@brightrain.aerifal.cx> <20170213171236.GI1520@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=f403045f8b546af71f0549e31802 X-Trace: blaine.gmane.org 1488614641 26180 195.159.176.226 (4 Mar 2017 08:04:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 08:04:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11112-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 04 09:03:56 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ck4fT-00067z-GW for gllmg-musl@m.gmane.org; Sat, 04 Mar 2017 09:03:55 +0100 Original-Received: (qmail 19767 invoked by uid 550); 4 Mar 2017 08:03:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19580 invoked from network); 4 Mar 2017 08:03:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=h+iv31yQbB7lda/ogPNz7aJS0x3v0ubPVMfu0qVeFVA=; b=vJhvzWcWEtT9gq0CnYcs2YNZyzqFphC36iyjDpsNjXUNUGW5Lzy5LCy2qPW3rY+p1m Jd7ALis5b1Irr5ekSrRFwTTTw1bIcJ89BdymXD8adJJ6Xbz8RCZyT9n8KwXjE0YAC35v j5UnucqGTg1Su/rDpmfswcappXlm4Sv6s9Yu9R16byqQEs7Ywggi2R0Q9A9mLp5W8ti2 cuebuYltFcNcM8vYvbpcUYT1fInkAasnJ3YMp5c2JIdKQCEfu/UA8krqrI3oyA1WR6g1 yIyFz2SfAlfTEGSGD81hO4Z0nGlfy9X6BAfAQvDUZrqiiEukQP0rTf12aVeF147lLFbx kb9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=h+iv31yQbB7lda/ogPNz7aJS0x3v0ubPVMfu0qVeFVA=; b=kYnvIHHadInpkQ1pAv6i4HECwyHeryd/2UnWaGxb/MbMoTv6ATpN8mSQVRd0UxphZA uZZelspTbor/eigZ5YL7sKQWHpNysv6949n7d0LR/4n6IMYV1g2LSY5Q6xQQ9lO05Lzn OQl2th99KDbGKvGYAiq88rNQIWPwXU7EkdNA5FgHOPte4/iKBUaR6hmqvwpfui7ywbCt kP10oQxEReCaJy81RpTE/UGwqHrEWZ+AvZr5PXDiDlb0ha73rHAgE+fxi0XfSIvSREJN UyPq7NBdIMs269F1BH+amxifhovI4E9oERoNB9GD6PUlROQAc7da6BiZbFXpjMBmsoa0 tR9Q== X-Gm-Message-State: AMke39lPM37z0OLp26sHgytLrtm09OJWa8vS/UIcqyur13JJYRx4oFLmYiHbZ+MMkg4x1uVHqIFwpwRCXDJoiA== X-Received: by 10.176.22.198 with SMTP id g6mr2261786uaf.112.1488614599596; Sat, 04 Mar 2017 00:03:19 -0800 (PST) In-Reply-To: <20170213171236.GI1520@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11097 Archived-At: --f403045f8b546af71f0549e31802 Content-Type: multipart/alternative; boundary=f403045f8b546af71b0549e31800 --f403045f8b546af71b0549e31800 Content-Type: text/plain; charset=UTF-8 OK, i am busy on school these days. I read the mailing lists again, and i clean up. These are all remaining issues we need to solve since previous discussion: 1. about zero msgid1, i can prove that glibc will fallback to no translations. It's equal to printf(""), so this should be ok: @@ -120,8 +122,9 @@ + if (!msgid1) goto notrans; > but it should be a separate patch since it's an independent change. (added in the head of dcngettext(), ill send a new standalone mail for this, but it's also included in this patch, be careful) 2. >But if the locale name is explicitly non-UTF-8 like "zh_CN.GBK", we could opt to reject it without breaking anything, and this may give users better feedback about what's going wrong if they have such settings when ssh'ing into a musl-based system. About the .GBK(and any other non-UTF8 charsets), i ignore them by treating them as C.UTF-8, do we need to be more strict? --- musl-1.1.16/src/locale/locale_map.c 2017-01-01 03:27:17.000000000 +0000 +++ musl-1.1.16/src/locale/locale_map.c 2017-01-01 03:27:17.000000000 +0000 @@ -46,7 +46,8 @@ if (val[0]=='.' || val[n]) val = "C.UTF-8"; int builtin = (val[0]=='C' && !val[1]) || !strcmp(val, "C.UTF-8") - || !strcmp(val, "POSIX"); + || !strcmp(val, "POSIX") + || strcmp(__strchrnul(val, '.'), ".UTF-8"); if (builtin) { if (cat == LC_CTYPE && val[1]=='.') 3. >The autoconf text for gettext is supposed to be getting fixed not to do that anymore, but I'm not sure what the progress on upstreaming it is. It's just a workaround before they handle it, and i am not going to change anything in musl, just a description. I only patched myself. 4. > Support for non-UTF-8 .mo files won't be added. > msgfmt just needs to be fixed not to produce non-UTF-8 output. I agreed with you, so then i hope '.UTF-8' could be kept. Rather than stripping it as i thought before, '.UTF-8' should be kept until the code went into dcngettext(). What if the .mo files are downloaded from www? Or what if it's pre-generated in the releases of programs? (i guess that's why vim gave me GBK set, it must be pre-generated) And even with msgfmt generating UTF-8 outputs, what if programs still name the dir as zh_CN.UTF-8 instead of simply zh_CN? You can't say it's wrong, right? It's their preference how to name it. It's necessary for those who have a full name like zh_CN.UTF-8 instead of zh_CN. This's what i am trying to express now. 2017-02-14 1:12 GMT+08:00 Rich Felker : > On Mon, Feb 13, 2017 at 10:06:49PM +0800, He X wrote: > > no, it's on musl, i just tested it with my patches, with vim, stripping > > will lead to unknown characters. > > That's not a matter of the locale being non-UTF-8 (it's UTF-8) but of > the application doing something broken. The locale is UTF-8 because > nl_langinfo(CODESET) says it is and because mb/wc conversion functions > process UTF-8. That's what it means for the locale to be UTF-8. > > > I mean, .mo files under zh_CN/ of vim is GBK set, while zh_CN/ of other > > apps is UTF-8 set, that meas there may be other apps like vim, we should > be > > more cautious, add a check before map the .mo files, and fail non-UTF8 > set > > in setlocale. > > All musl locale files are required to be UTF-8. If an application has > translation files that are not UTF-8, they're not usable. This could > be fixed in the application or by using a fixed version of msgfmt that > converts to UTF-8 before producing the .mo file. > > > Btw, _nl_msg_cat_cntr & _nl_domain_bindings will block apps compiling > with > > the native intl of musl, and after i added a dump for these two symbols, > > The autoconf text for gettext is supposed to be getting fixed not to > do that anymore, but I'm not sure what the progress on upstreaming it > is. > > > gnu tar showed me segfaults, because he passed a zero msgid1 causing > > __mo_lookup segfault, we should add a check in dcngettext to avoid it(if > > (!msgid1) goto notrans;): > > > > #2 0x00007ffff7d82a6f in dcngettext (domainname=0x6737a0 "tar", > > msgid1=0x0, msgid2=0x0, n=1, > > category=5) at src/locale/dcngettext.c:211 > > Is it expecting gettext to return a null pointer in this case, or to > return something else (like the "header", i.e. the translation of "")? > I think it's acceptable to change this behavior as long as we do it > right, but it should be a separate patch since it's an independent > change. > > Rich > --f403045f8b546af71b0549e31800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, i am busy on school these days. I read the mailin= g lists again, and i clean up. These are all remaining issues we need to so= lve since previous discussion:

1. about zero msgid= 1, i can prove that glibc will fallback to no translations. It's equal = to printf(""), so this should be ok:
@@ -120,8 +122,9 @@
+ if (!msgid1) goto no= trans;

>=C2=A0but it should be a separate patch s= ince it's an independent
change.
(added in t= he head of dcngettext(), ill send a new standalone mail for this, but it= 9;s also included in this patch, be careful)

2.=C2=A0
>But if the locale name is explicitl= y
non-UTF-8 like "zh_CN.GBK", we could opt to reject it withou= t breaking
anything, and this may give users better feedback about what&= #39;s going
wrong if they have such settings when ssh'ing into a mus= l-based
system.

About the .GBK(and any other non-U= TF8 charsets), i ignore them by treating them as C.UTF-8, do we need to be = more strict?
=
--- musl-1.1= .16/src/locale/locale_map.c 2017-01-01 03:27:17.000000000 +0000
+++ musl-= 1.1.16/src/locale/locale_map.c 2017-01-01 03:27:17.000000000 +0000=
@@ -46= ,7 +46,8 @@
=C2=A0 if (val[0]=3D=3D'.' || val[n]) val =3D "= C.UTF-8";
=C2=A0 int builtin =3D (val[0]=3D=3D'C' &&= !val[1])
=C2=A0 || !strcmp(val, "C.UTF-8")
- || !strcmp(va= l, "POSIX");
<= span style=3D"font-size:12px">+ || !strcmp(val, "POSIX")
+ || st= rcmp(__strchrnul(val, '.'), ".UTF-8");
=C2=A0
=C2=A0 if (builtin) {
=C2=A0 if (cat =3D=3D LC_CTYPE && val[1]=3D= =3D'.')
3.=C2=A0
>The autoconf text= for gettext is supposed to be getting fixed not to
do that anymore, b= ut I'm not sure what the progress on upstreaming it
is.
It's= just a workaround before they handle it, and i am not going to change anyt= hing in musl, just a description. I only patched myself.
4.
=C2=A0= >=C2=A0Support for non-UTF-8 .mo files won't be add= ed.
>=C2=A0msgfmt just needs to be fixed not to prod= uce
non-UTF-8 output.

I agreed with you= , so then i hope '.UTF-8' could be kept. Rather than stripping it a= s i thought before,=C2=A0'.UTF-8' should be kept until the code went in= to dcngettext(). What if the .mo files are downloaded from www? Or what if it&#= 39;s pre-generated in the releases of programs? (i guess that's why vim= gave me GBK set, it must be pre-generated)

And even with msgf= mt generating UTF-8 outputs,=C2=A0what if programs still name the dir as zh_CN.= UTF-8 instead of simply zh_CN? You can't say it's wrong, right? It&= #39;s their=C2=A0preference how to name it.

It's necessar= y for those who have a full name like zh_CN.UTF-8 instead of zh_CN. This= 9;s what i am trying to express now.

2017-02-14 1:12 GMT+08:00 Rich = Felker <dalias@libc.org>:
On Mon, Feb 13, 2017 at 10:06:49PM +0800, He X wrote:
> no, it's on musl, i just tested it with my patches, with vim, stri= pping
> will lead to unknown characters.

That's not a matter of the locale being non-UTF-8 (it's UTF-= 8) but of
the application doing something broken. The locale is UTF-8 because
nl_langinfo(CODESET) says it is and because mb/wc conversion functions
process UTF-8. That's what it means for the locale to be UTF-8.

> I mean, .mo files under zh_CN/ of vim is GBK set, while zh_CN/ of othe= r
> apps is UTF-8 set, that meas there may be other apps like vim, we shou= ld be
> more cautious, add a check before map the .mo files, and fail non-UTF8= set
> in setlocale.

All musl locale files are required to be UTF-8. If an application ha= s
translation files that are not UTF-8, they're not usable. This could be fixed in the application or by using a fixed version of msgfmt that
converts to UTF-8 before producing the .mo file.

> Btw, _nl_msg_cat_cntr & _nl_domain_bindings will block apps compil= ing with
> the native intl of musl, and after i added a dump for these two symbol= s,

The autoconf text for gettext is supposed to be getting fixed not to=
do that anymore, but I'm not sure what the progress on upstreaming it is.

> gnu tar showed me segfaults, because he passed a zero msgid1 causing > __mo_lookup segfault, we should add a check in dcngettext to avoid it(= if
> (!msgid1) goto notrans;):
>
>=C2=A0 #2=C2=A0 0x00007ffff7d82a6f in dcngettext (domainname=3D0x6737a0= "tar",
> msgid1=3D0x0, msgid2=3D0x0, n=3D1,
>=C2=A0 =C2=A0 =C2=A0category=3D5) at src/locale/dcngettext.c:211

Is it expecting gettext to return a null pointer in this case, or to=
return something else (like the "header", i.e. the translation of= "")?
I think it's acceptable to change this behavior as long as we do it
right, but it should be a separate patch since it's an independent
change.

Rich

--f403045f8b546af71b0549e31800-- --f403045f8b546af71f0549e31802 Content-Type: text/plain; charset=US-ASCII; name="locale.diff" Content-Disposition: attachment; filename="locale.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_izuynix90 LS0tIGEvc3JjL2xvY2FsZS9kY25nZXR0ZXh0LmMJMjAxNy0wMi0wNiAxNDozOToxNy44NjA0ODI2 MjQgKzAwMDAgCisrKyBiL3NyYy9sb2NhbGUvZGNuZ2V0dGV4dC5jCTIwMTctMDItMDYgMTQ6Mzk6 MTcuODYwNDgyNjI0ICswMDAwCkBAIC0xMDAsNyArMTAwLDkgQEAKIAlzaXplX3QgbWFwX3NpemU7 CiAJdm9pZCAqdm9sYXRpbGUgcGx1cmFsX3J1bGU7CiAJdm9sYXRpbGUgaW50IG5wbHVyYWxzOwot CWNoYXIgbmFtZVtdOworCXN0cnVjdCBiaW5kaW5nICpiaW5kaW5nOworCXN0cnVjdCBfX2xvY2Fs ZV9tYXAgKmxtOworCWludCBjYXQ7CiB9OwogCiBzdGF0aWMgY2hhciAqZHVtbXlfZ2V0dGV4dGRv bWFpbigpCkBAIC0xMjAsOCArMTIyLDkgQEAKKwlpZiAoIW1zZ2lkMSkgZ290byBub3RyYW5zOwog CXN0cnVjdCBtc2djYXQgKnA7CiAJc3RydWN0IF9fbG9jYWxlX3N0cnVjdCAqbG9jID0gQ1VSUkVO VF9MT0NBTEU7CiAJY29uc3Qgc3RydWN0IF9fbG9jYWxlX21hcCAqbG07Ci0JY29uc3QgY2hhciAq ZGlybmFtZSwgKmxvY25hbWUsICpjYXRuYW1lOwotCXNpemVfdCBkaXJsZW4sIGxvY2xlbiwgY2F0 bGVuLCBkb21sZW47CisJc2l6ZV90IGRvbWxlbjsKKwlzdHJ1Y3QgYmluZGluZyAqcTsKIAogCWlm ICgodW5zaWduZWQpY2F0ZWdvcnkgPj0gTENfQUxMKSBnb3RvIG5vdHJhbnM7CiAKQEAgLTEzMCw0 NyArMTMyLDY0IEBACiAJZG9tbGVuID0gc3Rybmxlbihkb21haW5uYW1lLCBOQU1FX01BWCsxKTsK IAlpZiAoZG9tbGVuID4gTkFNRV9NQVgpIGdvdG8gbm90cmFuczsKIAotCWRpcm5hbWUgPSBnZXR0 ZXh0ZGlyKGRvbWFpbm5hbWUsICZkaXJsZW4pOwotCWlmICghZGlybmFtZSkgZ290byBub3RyYW5z OworCWZvciAocT1iaW5kaW5nczsgcTsgcT1xLT5uZXh0KQorCQlpZiAoIXN0cmNtcChxLT5kb21h aW5uYW1lLCBkb21haW5uYW1lKSAmJiBxLT5hY3RpdmUpCisJCQlicmVhazsKKwlpZiAoIXEpIGdv dG8gbm90cmFuczsKIAogCWxtID0gbG9jLT5jYXRbY2F0ZWdvcnldOwogCWlmICghbG0pIHsKIG5v dHJhbnM6CiAJCXJldHVybiAoY2hhciAqKSAoKG4gPT0gMSkgPyBtc2dpZDEgOiBtc2dpZDIpOwog CX0KLQlsb2NuYW1lID0gbG0tPm5hbWU7Ci0KLQljYXRuYW1lID0gY2F0bmFtZXNbY2F0ZWdvcnld OwotCWNhdGxlbiA9IGNhdGxlbnNbY2F0ZWdvcnldOwotCWxvY2xlbiA9IHN0cmxlbihsb2NuYW1l KTsKLQotCXNpemVfdCBuYW1lbGVuID0gZGlybGVuKzEgKyBsb2NsZW4rMSArIGNhdGxlbisxICsg ZG9tbGVuKzM7Ci0JY2hhciBuYW1lW25hbWVsZW4rMV0sICpzID0gbmFtZTsKLQotCW1lbWNweShz LCBkaXJuYW1lLCBkaXJsZW4pOwotCXNbZGlybGVuXSA9ICcvJzsKLQlzICs9IGRpcmxlbiArIDE7 Ci0JbWVtY3B5KHMsIGxvY25hbWUsIGxvY2xlbik7Ci0Jc1tsb2NsZW5dID0gJy8nOwotCXMgKz0g bG9jbGVuICsgMTsKLQltZW1jcHkocywgY2F0bmFtZSwgY2F0bGVuKTsKLQlzW2NhdGxlbl0gPSAn Lyc7Ci0JcyArPSBjYXRsZW4gKyAxOwotCW1lbWNweShzLCBkb21haW5uYW1lLCBkb21sZW4pOwot CXNbZG9tbGVuXSA9ICcuJzsKLQlzW2RvbWxlbisxXSA9ICdtJzsKLQlzW2RvbWxlbisyXSA9ICdv JzsKLQlzW2RvbWxlbiszXSA9IDA7CiAKIAlmb3IgKHA9Y2F0czsgcDsgcD1wLT5uZXh0KQotCQlp ZiAoIXN0cmNtcChwLT5uYW1lLCBuYW1lKSkKKwkJaWYgKHAtPmJpbmRpbmcgPT0gcSAmJiBwLT5s bSA9PSBsbSAmJiBwLT5jYXQgPT0gY2F0ZWdvcnkpCiAJCQlicmVhazsKIAogCWlmICghcCkgewor CQljb25zdCBjaGFyICpkaXJuYW1lLCAqbG9jbmFtZSwgKmNhdG5hbWU7CisJCXNpemVfdCBkaXJs ZW4sIGxvY2xlbiwgY2F0bGVuOwogCQl2b2lkICpvbGRfY2F0czsKIAkJc2l6ZV90IG1hcF9zaXpl OwotCQljb25zdCB2b2lkICptYXAgPSBfX21hcF9maWxlKG5hbWUsICZtYXBfc2l6ZSk7CisKKwkJ ZGlybmFtZSA9IHEtPmRpcm5hbWU7CisJCWxvY25hbWUgPSBsbS0+bmFtZTsKKwkJY2F0bmFtZSA9 IGNhdG5hbWVzW2NhdGVnb3J5XTsKKworCQlkaXJsZW4gPSBxLT5kaXJsZW47CisJCWxvY2xlbiA9 IHN0cmxlbihsb2NuYW1lKTsKKwkJY2F0bGVuID0gY2F0bGVuc1tjYXRlZ29yeV07CisKKwkJc2l6 ZV90IG5hbWVsZW4gPSBkaXJsZW4rMSArIGxvY2xlbisxICsgY2F0bGVuKzEgKyBkb21sZW4rMzsK KwkJY2hhciBuYW1lW25hbWVsZW4rMV07CisJCWNoYXIgbG9jYnVmW2xvY2xlbisxXSwgKmxvY3Ag PSBsb2NidWY7CisJCWNvbnN0IHZvaWQgKm1hcDsKKworCQltZW1jcHkobG9jYnVmLCBsb2NuYW1l LCBsb2NsZW4pOworCQlsb2NidWZbbG9jbGVuXSA9IDA7CisKKwkJZm9yICg7OykgeworCQkJc25w cmludGYobmFtZSwgbmFtZWxlbisxLCAiJXMvJXMvJXMvJXMubW9cMCIsIGRpcm5hbWUsIGxvY2J1 ZiwgY2F0bmFtZSwgZG9tYWlubmFtZSk7CisJCQlpZiAobWFwID0gX19tYXBfZmlsZShuYW1lLCAm bWFwX3NpemUpKSBicmVhazsKKworCQkJaWYgKGxvY3AgPSBzdHJjaHIobG9jYnVmLCAnLicpKSB7 CisJCQkJKmxvY3AgPSAwOworCQkJfSBlbHNlIGlmIChsb2NwID0gc3RyY2hyKGxvY2J1ZiwgJ0An KSkgeworCQkJCSpsb2NwID0gMDsKKwkJCQlsb2NidWZbbG9jbGVuXSA9ICdAJzsKKwkJCX0gZWxz ZSBpZiAobG9jcCA9IHN0cmNocihsb2NidWYsICdfJykpIHsKKwkJCQlpZiAobG9jYnVmW2xvY2xl bl0gPT0gJ0AnKSB7CisJCQkJCWxvY2J1Zltsb2NsZW5dID0gMDsKKwkJCQkJKmxvY3AgPSAnQCc7 CisJCQkJCXN0cmNhdChsb2NwKzEsIGxvY2J1ZiArIHN0cmxlbihsb2NidWYpICsgMSk7CisJCQkJ fSBlbHNlICpsb2NwID0gMDsKKwkJCX0gZWxzZSB7CisJCQkJYnJlYWs7CisJCQl9CisJCX0KIAkJ aWYgKCFtYXApIGdvdG8gbm90cmFuczsKKwogCQlwID0gY2FsbG9jKHNpemVvZiAqcCArIG5hbWVs ZW4gKyAxLCAxKTsKIAkJaWYgKCFwKSB7CiAJCQlfX211bm1hcCgodm9pZCAqKW1hcCwgbWFwX3Np emUpOwpAQCAtMTc4LDcgKzE5NSw5IEBACiAJCX0KKyAJCXAtPmNhdCA9IGNhdGVnb3J5OworIAkJ cC0+YmluZGluZyA9IHE7CisgCQlwLT5sbSA9IGxtOwogCQlwLT5tYXAgPSBtYXA7CiAJCXAtPm1h cF9zaXplID0gbWFwX3NpemU7Ci0JCW1lbWNweShwLT5uYW1lLCBuYW1lLCBuYW1lbGVuKzEpOwog CQlkbyB7CiAJCQlvbGRfY2F0cyA9IGNhdHM7CiAJCQlwLT5uZXh0ID0gb2xkX2NhdHM7Ci0tLSBt dXNsLTEuMS4xNi9zcmMvbG9jYWxlL2xvY2FsZV9tYXAuYwkyMDE3LTAxLTAxIDAzOjI3OjE3LjAw MDAwMDAwMCArMDAwMAorKysgbXVzbC0xLjEuMTYvc3JjL2xvY2FsZS9sb2NhbGVfbWFwLmMJMjAx Ny0wMS0wMSAwMzoyNzoxNy4wMDAwMDAwMDAgKzAwMDAKQEAgLTQ2LDcgKzQ2LDggQEAKIAlpZiAo dmFsWzBdPT0nLicgfHwgdmFsW25dKSB2YWwgPSAiQy5VVEYtOCI7CiAJaW50IGJ1aWx0aW4gPSAo dmFsWzBdPT0nQycgJiYgIXZhbFsxXSkKIAkJfHwgIXN0cmNtcCh2YWwsICJDLlVURi04IikKLQkJ fHwgIXN0cmNtcCh2YWwsICJQT1NJWCIpOworCQl8fCAhc3RyY21wKHZhbCwgIlBPU0lYIikKKwkJ fHwgc3RyY21wKF9fc3RyY2hybnVsKHZhbCwgJy4nKSwgIi5VVEYtOCIpOwogCiAJaWYgKGJ1aWx0 aW4pIHsKIAkJaWYgKGNhdCA9PSBMQ19DVFlQRSAmJiB2YWxbMV09PScuJykK --f403045f8b546af71f0549e31802--