Hi Max,
Max Bowsher wrote on Thursday, March 29, 2007 1:46 PM:
> Max Bowsher wrote:
>> John Casey wrote:
>>> Max: I'm tempted to say that we should look for decimal versions of
>>> common octal expressions, then prefix the rest with '0' to ensure
>>> they're interpreted as octal (unless they have 0x in front, that
>>> is).
>>>
>>> Is that a decent solution?
>>
>> I think that it is the best compromise between maintaining the same
>> behaviour with existing descriptors, and fixing the bug going
>> forward into the future.
>>
>>
>> Would this behaviour apply to all modes in the descriptor, or just
>> <file><fileMode> ? (I'd lean toward the latter).
>>
>>
>> OOI, why prepend a leading zero, rather than using
>> Integer.parseInt(x,8) and Integer.parseInt(x,10) as appropriate? I
>> was thinking of something along the lines of:
>>
>> HashMap commonModes = new HashMap() {{
>> add("
>
> Oh, grr. I'd really like to know how Thunderbird managed to save a
> previous version than was showing when I did save-to-Drafts.
>
> Anyway, I meant:
>
> private static HashMap commonDecimalModes = new HashMap() {{
> add("420"); add("436");
> add("493");
> add("509");
> }}
>
> .....
>
> if ( commonDecimalModes.contains( mode ) )
> return Integer.parseInt( mode, 10 );
> else
> return Integer.parseInt( mode, 8 );
Why not letting Java decide? It handles decimal, octal and hex values
automatically:
public Integer fromString(String str) {
long value = Long.decode(str).longValue();
if(value < Integer.MIN_VALUE || value > 0xFFFFFFFFl) {
throw new NumberFormatException("For input string: \"" + str +
'"');
}
return new Integer((int)value);
}
Note: Integer.decode(String) is not used here because it will not handle
negative hex-coded integer values. With this approach you can express -1 as
0xFFFFFFFF ...
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
