January 22, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On 2014-01-21 22:07, Brian Schott wrote: > "test.d(10): Error: undefined identifier coverity_warnings" > > In order for this to work the analysis tool would have to distribute a > .d or .di file that is imported by any module that needs to suppress > warnings. Java has the SuppressWarnings annotation in the standard > java.lang to avoid this. Or just use an ugly string: @("coverity_warnings") -- /Jacob Carlborg |
January 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | On 1/20/2014 8:34 PM, Brian Schott wrote: > There's a small feature wishlist in the project's README, but I'd like to get > some opinions from the newsgroup: What kinds of errors have you seen in your > code that you think a static analysis tool could help with? Here's a great source of potential rules to add: http://www.stroustrup.com/JSF-AV-rules.pdf |
April 21, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | I just added two new rules, a check for if/else blocks that are identical and a check for assign expressions where the left and right side of the '=' operator are the same. It found two bugs in Phobos: https://issues.dlang.org/show_bug.cgi?id=12609 https://issues.dlang.org/show_bug.cgi?id=12608 |
April 22, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | Implicit conversion long - size_t - int. Null dereference can sometimes be detected statically, e.g. when the variable is not initialized. Possible null dereference after downcast, though this one can be annoying. I suggest to configure warnings with a config file, as the configuration can be big depending on the project code style. Another possibility is optional pragmas for really evil local overrides - resharper style comments - not only analysis tools can benefit from them. |
April 22, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | Also escape analysis. Bug found by frama-c: http://blog.frama-c.com/index.php?post/2014/02/23/CVE-2013-5914 Quote: "Allow me to put it this way: if the Apple SSL bug is a coup from the NSA, then you US citizens are lucky. Our spy agency in Europe is so much better that it does not even have a name you have heard before, and it is able to plant bugs where the buffer overflow leading to arbitrary code execution is three function calls away from the actual bug. The bug from our spy agency is so deniable that the code actually used to be fine when there were only two minor revisions of the SSL protocol. The backdoors from your spy agency are so lame that the Internet has opinions about them." |
April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brian Schott | Am Tue, 21 Jan 2014 04:34:56 +0000 schrieb "Brian Schott" <briancschott@gmail.com>: > There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with? Yes, this one: size_t shiftAmount = 63; […] auto x = 1 << shiftAmount; The trouble is that auto will now resolve to int instead of size_t as indicated by the type of shiftAmount. Sure, my fault was to use an innocent »1« instead of »cast(size_t) 1«. So the result is: int x = -2147483648; But »1 << size_t« doesn't always yield an int result! Compare to this: size_t x = 1 << shiftAmount; which becomes: size_t x = 18446744071562067968; Two possible warnings could be: - Shifting an »int« by a »size_t« is not the correct way to enforce a »size_t« result. Please use »cast(size_t) 1 << shiftAmount« if that was the intention. - »auto« variable definition will resolve to »int« and may lose information from expression »1 << shiftAmount«. Please replace »auto« with »int« if that is what you want or set the correct data type otherwise. In both cases an explicit mention of a data type resolves the ambiguity. -- Marco |
April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:
> Am Tue, 21 Jan 2014 04:34:56 +0000
> schrieb "Brian Schott" <briancschott@gmail.com>:
>
>> There's a small feature wishlist in the project's README, but I'd
>> like to get some opinions from the newsgroup: What kinds of
>> errors have you seen in your code that you think a static
>> analysis tool could help with?
>
> Yes, this one:
>
> size_t shiftAmount = 63;
> […]
> auto x = 1 << shiftAmount;
>
> The trouble is that auto will now resolve to int instead of
> size_t as indicated by the type of shiftAmount. Sure, my fault
> was to use an innocent »1« instead of »cast(size_t) 1«.
You could use 1UL instead.
-Steve
|
April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Am Wed, 23 Apr 2014 22:56:27 -0400 schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>: > On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise <Marco.Leise@gmx.de> wrote: > > > Am Tue, 21 Jan 2014 04:34:56 +0000 > > schrieb "Brian Schott" <briancschott@gmail.com>: > > > >> There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with? > > > > Yes, this one: > > > > size_t shiftAmount = 63; > > […] > > auto x = 1 << shiftAmount; > > > > The trouble is that auto will now resolve to int instead of size_t as indicated by the type of shiftAmount. Sure, my fault was to use an innocent »1« instead of »cast(size_t) 1«. > > You could use 1UL instead. > > -Steve No, that would give you a ulong result. -- Marco |
April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | On 04/24/14 04:56, Marco Leise via Digitalmars-d wrote: > But »1 << size_t« doesn't always yield an int result! Compare to It does. That expression *always* yields an int [1]. Assigning the result to a wider type does not affect the value (the overflow has already happened by then). > size_t x = 1 << shiftAmount; This would almost certainly be a bug, if shiftAmount could ever become greater than 30. The `size_t = 1<<31` case is also very unlikely to do what the programmer intended. > - »auto« variable definition will resolve to »int« and may > lose information from expression »1 << shiftAmount«. Please > replace »auto« with »int« if that is what you want or set > the correct data type otherwise. `size_t x = 1 << shiftAmount` is definitely not something that should be recommended, see above. Just use the correct type on the lhs of shift operators. artur [1] there could be an exception for certain compile-time contexts, but I don't think that would work in D (same code would give different results when run at CT and RT). |
April 24, 2014 Re: Static Analysis Tooling / Effective D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Artur Skawina | Am Thu, 24 Apr 2014 13:11:18 +0200 schrieb Artur Skawina via Digitalmars-d <digitalmars-d@puremagic.com>: > `size_t x = 1 << shiftAmount` is definitely not something that should be recommended, see above. Just use the correct type on the lhs of shift operators. auto x = cast(size_t) 1 << shiftAmount; // really ?! :( In that case it is better to define ONE as a constant :) enum ONE = cast(size_t) 1; auto x = ONE << shiftAmount; -- Marco |
Copyright © 1999-2021 by the D Language Foundation