=== 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 11 Dec 2015, 08:58:50 Tamas Vajk wrote:
\[~ann.campbell.2] applied some changes to the description

=== on 11 Dec 2015, 13:57:58 Ann Campbell wrote:
looks good

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

=== on 21 Jul 2016, 14:39:03 Ann Campbell wrote:
\[~tamas.vajk] I've tweaked the wording of your addition. Please double-check me.

=== on 21 Jul 2016, 15:24:29 Tamas Vajk wrote:
\[~ann.campbell.2] "known-empty" is strange for me, I would probably go with simply "empty" if the original variant was not good.

=== on 21 Jul 2016, 15:38:42 Ann Campbell wrote:
Second attempt made [~tamas.vajk]

=== on 21 Jul 2016, 15:41:08 Tamas Vajk wrote:
\[~ann.campbell.2] perfect, thanks.

=== 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].


=== on 08 Jun 2023, 16:45:00 Sébastien Marichal wrote:

During a LaYC sprint, I removed dummy implementations for the following language:

* abap
* flex
* javascript
* python

It is not implemented in the corresponding analyzer and there currently are no tickets open in order to do so.
