Re: Feedback wanted: fix approach for JB 4255?
George Rhoten <[email protected]> Wed, 1 Dec 2004 10:17:19 -0800
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <OF40F0BDC7.7F6F57DB-ON86256F5D.006405DE-88256F5D.00644DB2@us.ibm.com> |
This is a multipart message in MIME format. --=_alternative 00644DAB88256F5D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Since you happen to be in that code, did you want to fix it so that it=20 also addresses jitterbug 4069? I don't see much point to redoing the=20 code, if it has to be redone to support different functionality in the=20 future. Also you submitted the 4096 bug, and I presume that you have a=20 vested interest in implementing it ;-) George Rhoten IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA Deborah Goldsmith <[email protected]>=20 Sent by: [email protected] 12/01/2004 09:19 AM To icu list <[email protected]> cc Subject Re: Feedback wanted: fix approach for JB 4255? OK, I'll proceed with the approach I proposed. Deborah On Nov 29, 2004, at 5:59 PM, Deborah Goldsmith wrote: > Any comments? > > Deborah > > On Nov 19, 2004, at 5:12 PM, Deborah Goldsmith wrote: >> Hi, >> >> I just encountered JB 4255, which is yet another problem with setting=20 >> warnings properly when fetching display names, this time in=20 >> uloc=5FgetDisplayName. The problem is that each individaul=20 >> uloc=5FgetDisplay* smashes the incoming status code, so the code=20 >> returned by uloc=5FgetDisplayName is the one from the last component of = >> the name, not the union of any warnings encountered. You can read the=20 >> bug for a slightly lengthier explanation. >> >> I know this is too late for 3.2, but I need to fix this in my copy.=20 >> My proposed fix is to change uloc=5FgetDisplay* to not smash the=20 >> incoming error code when calling uloc=5Fget*. uloc=5FgetDisplay* already= =20 >> sets the output code if an error occurs, so we might as well use a=20 >> local status code for the call to uloc=5Fget*; that would preserve the=20 >> incoming code. Does this seem like a reasonable approach? The other=20 >> approach would be to have uloc=5FgetDisplayName manually merge the=20 >> warning codes from the component calls. >> >> By the way, uloc=5FgetDisplay(Language/Script/Country/Variant) could=20 >> share a common worker routine and just pass a pointer to a function=20 >> to get the desired component, since=20 >> uloc=5Fget(Language/Script/Country/Variant) all share the same=20 >> signature. That would save a bit of code. I filed JB 4256 for that. >> >> Deborah > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > icu mailing list > [email protected] > http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F icu mailing list [email protected] http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu --=_alternative 00644DAB88256F5D_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <br><font size=3D2 face=3D"sans-serif">Since you happen to be in that code, did you want to fix it so that it also addresses jitterbug 4069? I don't see much point to redoing the code, if it has to be redone to support different functionality in the future. Also you submitted the 4096 bug, and I presume that you have a vested interest in implementing it ;-)</= font> <br><font size=3D2 face=3D"sans-serif"><br> George Rhoten<br> IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA</font> <br> <br> <br> <table width=3D100%> <tr valign=3Dtop> <td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Deborah Goldsmith <= ;[email protected]></b> </font> <br><font size=3D1 face=3D"sans-serif">Sent by: [email protected]= .usf.ibm.com</font> <p><font size=3D1 face=3D"sans-serif">12/01/2004 09:19 AM</font> <td width=3D59%> <table width=3D100%> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div> <td valign=3Dtop><font size=3D1 face=3D"sans-serif">icu list <icu@www-12= 4.southbury.usf.ibm.com></font> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div> <td valign=3Dtop> <tr> <td> <div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div> <td valign=3Dtop><font size=3D1 face=3D"sans-serif">Re: Feedback wanted: fix approach for JB 4255?</font></table> <br> <table> <tr valign=3Dtop> <td> <td></table> <br></table> <br> <br> <br><font size=3D2><tt>OK, I'll proceed with the approach I proposed.<br> <br> Deborah<br> <br> On Nov 29, 2004, at 5:59 PM, Deborah Goldsmith wrote:<br> <br> > Any comments?<br> ><br> > Deborah<br> ><br> > On Nov 19, 2004, at 5:12 PM, Deborah Goldsmith wrote:<br> >> Hi,<br> >><br> >> I just encountered JB 4255, which is yet another problem with setting <br> >> warnings properly when fetching display names, this time in <br> >> uloc=5FgetDisplayName. The problem is that each individaul <br> >> uloc=5FgetDisplay* smashes the incoming status code, so the code <br> >> returned by uloc=5FgetDisplayName is the one from the last compone= nt of <br> >> the name, not the union of any warnings encountered. You can read the <br> >> bug for a slightly lengthier explanation.<br> >><br> >> I know this is too late for 3.2, but I need to fix this in my copy. <br> >> My proposed fix is to change uloc=5FgetDisplay* to not smash the <br> >> incoming error code when calling uloc=5Fget*. uloc=5FgetDisplay* a= lready <br> >> sets the output code if an error occurs, so we might as well use a <br> >> local status code for the call to uloc=5Fget*; that would preserve the <br> >> incoming code. Does this seem like a reasonable approach? The other <br> >> approach would be to have uloc=5FgetDisplayName manually merge the <br> >> warning codes from the component calls.<br> >><br> >> By the way, uloc=5FgetDisplay(Language/Script/Country/Variant) cou= ld <br> >> share a common worker routine and just pass a pointer to a function <br> >> to get the desired component, since <br> >> uloc=5Fget(Language/Script/Country/Variant) all share the same <br> >> signature. That would save a bit of code. I filed JB 4256 for that.<br> >><br> >> Deborah<br> ><br> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br> > icu mailing list<br> > [email protected]<br> > http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu<br> <br> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br> icu mailing list<br> [email protected]<br> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu<br> </tt></font> <br> --=_alternative 00644DAB88256F5D_=--