[Mono-list] conversions

Jambunathan Jambunathan kjambunathan@novell.com
Fri, 08 Oct 2004 04:01:09 -0600

```Thanks a lot for an enlightening conversation.

I have created the folowing  bug report to keep track
of the  same.

http://bugzilla.ximian.com/show_bug.cgi?id=67810

Regards,
Jambunathan K.

>>> "Jonathan Gilbert" <2a5gjx302@sneakemail.com> 10/08/04 5:05 AM >>>
At 06:57 AM 06/10/2004 -0400, Jonathan Pryor wrote:
>On Wed, 2004-10-06 at 03:59, Polton, Richard (IT) wrote:
>> If the char which is to be converted is 0661, say, then what will be
the
>> value of the subtraction? Will it be 0661 - 0660 or will it be 0661
-
>> 0030? I assume that a literal '0' will always map to 0030 rather
than
>> cleverly detect the range of digits that the char belongs to.
>
>Oh.  Good point.  (Why didn't I think of that?)  The literal '0' is
>mapped to 0030, so  you'd get U+0661 - U+0030, which is *way* too
big.
>
>So I guess the code is broken.  The question is, in what way? :-/
>
>Now the question is: what does Microsoft's implementation do? :-)
>
>Someone will have to throw U+0661 at Microsoft's
>Microsoft.VisualBasic.dll and see what the return value (or exception
>generated) is.  They may require a value between '0' and '9', and all
>other "Nd" digits, such as U+0661, generate exceptions.
>
>Alternatively, Microsoft always subtracts from the proper value.
>
>We can do either of these, we just need to know which to do.

I just wrote a simple test program using some of the ranges listed two
posts back. I threw "375", "\u0663\u0667\u0665", "\u09E9\u09ED\u09EB",
and,
for kicks, the native Japanese representation, 5 kanji long,
"\u4E09\u767E\u4E03\u5341\u4E94" (sambyaku nanajuu go). Here are the
results:

int.Parse(..):
Arabic: 375
Arabic-Indic: ERROR: FormatException
Bengali: ERROR: FormatException
Japanese: ERROR: FormatException
VB.NET's Val(..):
Arabic: 375
Arabic-Indic: 0
Bengali: 0
Japanese: 0

When I concatenate the arabic-indic script to the arabic script
(yielding
the string "375\u0663\u0667\u0665"), VB's Val() function returns "375".
In
other words, int.Parse() should throw when it gets something that isn't
in
['0', '9'] (or relevant punctuation), and
Microsoft.VisualBasic.Conversion.Val() should stop parsing when it
reaches
the first such character.

Hope this helps :-)

Jonathan Gilbert

_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

```