Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 362961 - The same compare statement has different returned value between EDT & RBD
Summary: The same compare statement has different returned value between EDT & RBD
Status: CLOSED INVALID
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: EDT (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-05 04:05 EDT by fahua jin CLA
Modified: 2017-02-23 14:15 EST (History)
7 users (show)

See Also:


Attachments
The sample EGL file. (543 bytes, application/octet-stream)
2011-11-05 04:06 EDT, fahua jin CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description fahua jin CLA 2011-11-05 04:05:58 EDT
Build Identifier: 0.7.0.v201111032101

1) Open the attached H6.egl with VE, you can find that in the EDT it prints false, while in RBD is true.

Reproducible: Always
Comment 1 fahua jin CLA 2011-11-05 04:06:33 EDT
Created attachment 206487 [details]
The sample EGL file.
Comment 2 fahua jin CLA 2011-11-05 04:07:37 EDT
For your convenient, I copy the code in below.

    	constraints dictionary = new Dictionary{ min = 100};
    	input string = "4";
    	if(input  > constraints.min as int)
    		syslib.writeStdout("false");
    	else
    		syslib.writeStdout("true");
    	end
Comment 3 Yun Feng Ma CLA 2011-11-14 03:09:53 EST
I agree that the behavior of EDT and RBD is different, but I think the behavior of EDT is right: because "input" is a String type, the below comparison is for String, not int:
   if(input  > constraints.min as int)

Both JSGen ahd JavaGen in EDT have the same behavior, so I think this is worked as designed.

Below case is for int comparison:
   if(input as int  > constraints.min as int)


Brian, what do you think? Thanks.
Comment 4 Brian Svihovec CLA 2011-11-17 11:23:35 EST
I discussed this with Paul.  When doing a conversion of one type to another, we always Widen one type to match if we can.  If you look in EString.egl, there is a conversion from Int to String that is marked as 'widening':

static function asString(value EInt in) returns (EString) {@Operation{"widen"}};

This means that the comparison is "4" > "100".

This is different than RBD, but I spoke with Tim about this, and the widen is from int to String because a String to an int can throw an exception if the String does not contain a number.

Finally, after discussing this with Paul, the comparison appears to be implemented as a char[].  I spoke with Tim about this as well, and he believes that the implementation should be a locale based sort of the two strings (e.g. Collator).
Comment 5 Brian Svihovec CLA 2011-11-17 11:40:18 EST
NOTE: We can discuss the string comparison changes, and decide if we want to make any changes in EDT .7, but the main point is that the widening from int to string is the expected behavior.
Comment 6 Brian Svihovec CLA 2011-11-17 12:16:48 EST
After thinking about this more, let's not change the string comparison implementation in .7.
Comment 7 Matt Heitz CLA 2012-11-14 14:02:03 EST
The code is behaving properly.  Not a bug.
Comment 8 Matt Heitz CLA 2013-01-03 10:08:35 EST
Closing all bugs in the RESOLVED state with reason INVALID, WONTFIX, DUPLICATE, WORKSFORME, or NOT_ECLIPSE.