harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: svn commit: r725623 - /harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/x501/AttributeTypeAndValue.java
Date Mon, 15 Dec 2008 03:43:09 GMT
hmm,
Seems the non-cap strings are used for other reasons?
need some time to finger out. just created a JIRA for record, will do
that when I have time.
https://issues.apache.org/jira/browse/HARMONY-6046

On Thu, Dec 11, 2008 at 6:34 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Just an observation...
>
> tonywu@apache.org wrote:
>> @@ -311,7 +312,7 @@
>>              buf.append('=');
>>              if (value.escapedString == value.getHexString()) {
>>                  //FIXME all chars in upper case
>> -                buf.append(value.getHexString().toUpperCase());
>> +                buf.append(Util.toUpperCase(value.getHexString()));
>>              } else if (value.escapedString.length() != value.rawString.length())
{
>>                  // was escaped
>>                  value.appendQEString(buf);
>
> Seems odd in the first place to have converted the value to a hex string
> with the wrong capitalization, then create a new string with the right
> capitalization.
>
> What would break if we changed the impl of getHexString() to return caps
> rather than optimize the toUpperCase()?
>
> Regards,
> Tim
>



-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message