dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pnet-developers] [bugs #7016] output order for positive, negative and N


From: Deryk Robosson
Subject: [Pnet-developers] [bugs #7016] output order for positive, negative and NULL values is not correct
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 Galeon/1.3.17

This mail is an automated notification from the bugs tracker
 of the project: DotGNU Portable.NET.

/**************************************************************************/
[bugs #7016] Latest Modifications:

Changes by: 
                Deryk Robosson <address@hidden>
'Date: 
                Sun 10/24/2004 at 03:33 (GMT)

------------------ Additional Follow-up Comments ----------------------------
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.






/**************************************************************************/
[bugs #7016] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=7016>
Project: DotGNU Portable.NET
Submitted by: Rainer Groesslinger
On: Mon 12/29/2003 at 17:11

Category:  None
Severity:  5 - Average
Item Group:  None
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open


Summary:  output order for positive, negative and NULL values is not correct

Original Submission:  When running the attached test case it returns the 
following on MS .NET (as expected):
100.000
(100.000)
-

On pnet it returns:
10000.0
1000(0.0)
'-'

Follow-up Comments
------------------


-------------------------------------------------------
Date: Sun 10/24/2004 at 03:33       By: Deryk Robosson <drobosson>
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.






File Attachments
-------------------

-------------------------------------------------------
Date: Mon 12/29/2003 at 17:11  Name: output.cs  Size: 445B   By: scandium
test case for positive/negative/NULL values
http://savannah.gnu.org/bugs/download.php?item_id=7016&amp;item_file_id=916






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=7016>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]