=== relates to: S848

=== on 22 Oct 2014, 18:58:33 Nicolas Peru wrote:
Seems to me that the first phrase and the first non compliant code example contradicts. 

=== on 22 Oct 2014, 19:07:09 Ann Campbell wrote:
\[~nicolas.peru] twoThirds ends up with a value of 0.0, i.e. 0 cast to a float. How would you suggest I clarify?

=== on 22 Oct 2014, 19:28:42 Nicolas Peru wrote:
\[~ann.campbell.2]I understand the 1st phrase as "Everything goes fine if you multiply /divide int and assign them to float/long" whereas you explain afterward that there are issues.

The 2nd phrase of the 1st § should be : You can assign this result to a long, double or float with automatic type conversion however if the result of int division is... 

=== on 22 Oct 2014, 19:35:33 Ann Campbell wrote:
I get it now, [~nicolas.peru]. See what you think.

=== on 26 Nov 2014, 20:20:38 Freddy Mallet wrote:
Just to be sure [~ann.campbell.2] and [~nicolas.peru], Findbugs rule ICAST_INT_2_LONG_AS_INSTANT, also checks method calls. Ex:

----
new Date(seconds * 1000)  //non compliant if seconds is an int value (because the Date constructor accepts a long value and so we might get an unexpected behavior
----

Is it the case with the current implementation ?

=== on 27 Nov 2014, 06:51:09 Nicolas Peru wrote:
No, current implementation only check for assignement and variable initializers. I reopen the ticket to cover those cases.

=== on 27 Nov 2014, 07:50:02 Freddy Mallet wrote:
The return statement should also be covered. I'm going to update the code snippets.

=== on 30 Sep 2016, 16:22:15 Jean-Christophe Collet wrote:
Right now, the way it is worded, this rule doesn't address long integers. Assigning a ``++long++`` expression to a ``++float++`` or ``++double++`` has pretty much the same issues as ``++int++``.

Current implementation of Java scanner doesn't flag something like:

----
float f = 4l / 3;
----
I think we should cover this as well.

=== on 11 Dec 2016, 17:50:54 Nicolai Ommer wrote:
I recently found a statement where this rule should have triggered in my opinion, but hasn't:

----
double dt2 = (1 / 2) * dt * dt * sigma * sigma; // dt, sigma are double
----
It turned out that as soon as there is double value in the statement, the rule is not triggered, i.e.

----
double a = 1 / 2 * 5.0;
----

=== on 12 Dec 2016, 14:58:00 Ann Campbell wrote:
Hi Nicolai,


We greatly appreciate such feedback, but this isn't the proper venue. Please raise this on the https://groups.google.com/forum/?pli=1#!forum/sonarqube[SonarQube Google Group], which is monitored by the plugin developers. And when you do, make sure to mention which language you're talking about.



Thx!