=== is duplicated by: S1243

=== is related to: S2192

=== is related to: S855

=== is related to: S856

=== is related to: S859

=== replaces: S858

=== replaces: S870

=== replaces: S1256

=== on 8 Aug 2014, 21:17:40 Ann Campbell wrote:
2 items of note:

* spec-ed for C because of pointer casting
* tagged to CWE-588 because the mitigations section lists making sure your casts are appropriate. Don't know if this is too tenuous a link or not.

=== on 8 Sep 2014, 14:44:40 Ann Campbell wrote:
CERT lists these as relevant:

* MISRA C:2004, 11.4
* MISRA {cpp} 5-2-2
* MISRA {cpp} 5-2-3

Additionally, these seem relevant to me:

* MISRA C:2004, 10.3, 10.4, 11.1, 11.2, 11.3, 11.4, 11.5
* MISRA {cpp}:2008, 5-2-5, 5-2-6, 5-2-7, 5-2-8, 5-2-9
* MISRA C:2012, 10.3, 10.5, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7, 11.8

But is that "cast"-ing too broad a net?

=== on 1 Oct 2014, 08:19:25 Nicolas Peru wrote:
No issue for java for the scope regarding casting to unrelated type. 

But for me it is out of scope of this rule to detect untested ("untested" has to be define) down cast. This would require another rule I think.

=== on 1 Oct 2014, 11:55:24 Ann Campbell wrote:
\[~nicolas.peru], you couldn't look for the downcast to be inside an ``++instanceof++`` condition?

=== on 1 Oct 2014, 13:56:20 Nicolas Peru wrote:
\[~ann.campbell.2] If I take the example of the java syntax tree here is how we downcast : 


----
if(tree.is(Tree.Kind.TYPE_CAST)) {
  TypeCastTree typeCastTree = (TypeCastTree) tree;
}
----

and we even have some usages that are based on safe assumptions (SubscriptionVisitor) for instance.


So I tend to think that this usecase will trigger way too many false positive (at least in our codebase) to be useful.

=== on 1 Oct 2014, 14:22:53 Ann Campbell wrote:
\[~nicolas.peru] I would really like to see that case covered. A different rule? A parameter?

=== on 2 Oct 2014, 08:29:13 Nicolas Peru wrote:
In fact problem is the same as for the first case, see my comment in \http://jira.codehaus.org/browse/SONARJAVA-723 :  problem is to detect how the type has been tested.

=== on 23 May 2016, 19:05:51 Ann Campbell wrote:
Relevant for C? \http://programmers.stackexchange.com/a/319261/206730

=== on 1 Nov 2018, 17:12:42 Inna Nill wrote:
Is there a plan to implement this, for Java?

=== on 1 Nov 2018, 17:27:03 Ann Campbell wrote:
\[~innanill] if you'd like to start a discussion, please go to the https://community.sonarsource.com[SonarSource Community].

