DotGNU Portable.NET - Bugs: bug #7016, output order for positive,...
You are not allowed to post comments on this tracker with your current authentication level.
bug #7016: output order for positive, negative and NULL values is not correct
Submitter: | -Deleted Account- <scandium> | ||
Submitted: | Mon 29 Dec 2003 05:11:01 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Sun 24 Oct 2004 03:33:46 AM UTC, comment #1: |
Deryk Robosson <drobosson> |
Mon 29 Dec 2003 05:11:01 PM UTC, original submission:
When running the attached test case it returns the following on MS .NET (as expected):
|
-Deleted Account- <scandium> |
Attached Files
file #936: output.cs added by scandium (445B - application/octet-stream - test case for positive/negative/NULL values)
Depends on the following items: None found
Items that depend on this one: None found
CC list is empty
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2003-12-29 | scandium | Attached File | - | Added output.cs, #916 |
Powered by Savane 3.13-758e.
Corresponding source code
The fault for this lies somewhere within:
pnetlib/runtime/System/Private/NumberFormat/CustomFormatter.cs
One issue from what I can see appears that:
while (formatindex >=0 && format[formatindex] == groupSeparator)
{
scale += 3;
--formatindex;
}
Given the input of "123456" and format of "#,#", this will never get called with a "#,#" format as in this example, formatindex is set to length of the format minus one, so length = 3 - 1 = 2, the char at position two (array of 0 = '#', 1 = ',' , 2 = '#'). The second test condition of the while fails.
Setting the second test condition to a != test allows the decimal to be placed in the correct position in the numeric value passed in, however the padding doesn't seem to take place. While the MS.NET implementation would show 100.000 in the test case, I'm getting 123.<nothing> while using the != above. The MS.NET docs on numberformatting isn't exactly clear as to if the padding will be zeros or if the second number placeholder will be the remainder of the input numeric value (i.e. .456). I'm going cross eyed looking at this method, a fresh set of eyes may be good. If not, I'll revisit it at a later date.