commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (LANG-929) OctalUnescaper code is complex, leading to bugs
Date Sat, 26 Oct 2013 02:47:30 GMT

     [ https://issues.apache.org/jira/browse/LANG-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Henri Yandell resolved LANG-929.
--------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: Patch Needed)
                   3.2

svn ci -m "Rewriting OctalUnescaper as a hand rolled parser (all of 4 characters), instead
of trying to handle the conversion via repeated attempts to convert the numbers. This fixes
bugs, see LANG-929, and also changes the behaviour for 'illegal' octals such as \999. Instead
of throwing NumberFormatException, it will now ignore them. This seems the better behaviour.
"
Sending        src/main/java/org/apache/commons/lang3/text/translate/OctalUnescaper.java
Sending        src/test/java/org/apache/commons/lang3/text/translate/OctalUnescaperTest.java
Transmitting file data ..
Committed revision 1535914.


> OctalUnescaper code is complex, leading to bugs
> -----------------------------------------------
>
>                 Key: LANG-929
>                 URL: https://issues.apache.org/jira/browse/LANG-929
>             Project: Commons Lang
>          Issue Type: Improvement
>          Components: lang.text.translate.*
>            Reporter: Henri Yandell
>            Assignee: Henri Yandell
>             Fix For: 3.2
>
>
> My gut is that the code in OctalUnescaper is unnecessarily complex. It feels simpler
to look at the legitimate values for an Octal more explicitly. 
> Thinking the current code through, it fails if you pass it \279. That should be octal
\27 followed by a 9, but instead it will try to parse it as an Octal and throw a NumberFormatException.




--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message