Re: Static Analysis Tooling / Effective D
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 = 131` 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).
Re: Static Analysis Tooling / Effective D
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
Re: Static Analysis Tooling / Effective D
On 04/24/14 14:49, Marco Leise via Digitalmars-d wrote: 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 ?! :( Yes. D has not improved the situation in this area; it's no different from C. A new enough compiler could make it look slightly better: auto x = size_t(1) shiftAmount; Of course the more fundamental problem is that 'size_t' is just an alias and not a distinct type in D. artur
Re: Static Analysis Tooling / Effective D
On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise marco.le...@gmx.de wrote: Am Wed, 23 Apr 2014 22:56:27 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise marco.le...@gmx.de wrote: Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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. Hm... I was thinking in terms of 1 63, that must be a ulong, no? But I see your point that size_t may be 32 bits. I also think this will work: size_t(1); -Steve
Re: Static Analysis Tooling / Effective D
Am Thu, 24 Apr 2014 10:26:48 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise marco.le...@gmx.de wrote: Am Wed, 23 Apr 2014 22:56:27 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise marco.le...@gmx.de wrote: Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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. Hm... I was thinking in terms of 1 63, that must be a ulong, no? Actually in _that_ case the compiler will yell at you that the valid range to shift an »int« is [0..31]. But I see your point that size_t may be 32 bits. I also think this will work: size_t(1); -Steve Both you and Artur mentioned it. Will this generalized ctor syntax be in 2.066 ? It looks much less like code smell when you don't have to use a cast any more even if it is just a rewrite. -- Marco
Re: Static Analysis Tooling / Effective D
On Thu, 24 Apr 2014 15:40:23 -0400, Marco Leise marco.le...@gmx.de wrote: Am Thu, 24 Apr 2014 10:26:48 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 23:15:01 -0400, Marco Leise marco.le...@gmx.de wrote: Am Wed, 23 Apr 2014 22:56:27 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise marco.le...@gmx.de wrote: Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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. Hm... I was thinking in terms of 1 63, that must be a ulong, no? Actually in _that_ case the compiler will yell at you that the valid range to shift an »int« is [0..31]. *sigh* The compiler is too smart for it's own good ;) This SHOULD compile and result in a long. I can't see how you would have meant anything else, and range propagation should work for a literal. But I see your point that size_t may be 32 bits. I also think this will work: size_t(1); -Steve Both you and Artur mentioned it. Will this generalized ctor syntax be in 2.066 ? I don't know. I thought it was in 2.065, but see that it's not. I have read that it was introduced somewhere, so I assumed it was already in. Maybe only in git HEAD. It looks much less like code smell when you don't have to use a cast any more even if it is just a rewrite. Yeah definitely. Cast should not be required for such mundane and obviously safe things. -Steve
Re: Static Analysis Tooling / Effective D
Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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
Re: Static Analysis Tooling / Effective D
On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise marco.le...@gmx.de wrote: Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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
Re: Static Analysis Tooling / Effective D
Am Wed, 23 Apr 2014 22:56:27 -0400 schrieb Steven Schveighoffer schvei...@yahoo.com: On Wed, 23 Apr 2014 22:56:54 -0400, Marco Leise marco.le...@gmx.de wrote: Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@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
Re: Static Analysis Tooling / Effective D
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.
Re: Static Analysis Tooling / Effective D
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.
Re: Static Analysis Tooling / Effective D
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
Re: Static Analysis Tooling / Effective D
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
Re: Static Analysis Tooling / Effective D
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
Re: Static Analysis Tooling / Effective D
On 1/20/2014 8:34 PM, Brian Schott wrote: I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching Exception, and a few other things. 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? Automated source code formatting would be nice (and it's not as easy as it looks).
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote: Automated source code formatting would be nice (and it's not as easy as it looks). It has nothing to do with static analysis.
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote: I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching Exception, and a few other things. 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? I'd personally love to see most of existing DMD warnings moved to DScanner and, after it get some recognition, removed from compiler completely. That, of course, implies some way to tune output for specific project, supressing some of detection patterns. That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally?
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote: That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally? I assume you're talking about something like @SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 09:11:37 UTC, Brian Schott wrote: On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote: That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally? I assume you're talking about something like @SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html I was thinking of a more fine-tuned thing, similar to gcc `__attribute__ (unused)` but generalised a bit to not interfere with normal attributes by using reserved namespace. Single @SuppressWarnings (analysis reports in our case) can be a simpler compromise though.
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 09:22:16 UTC, Walter Bright wrote: Coverity (a static analyzer) does checks based on whitespace indentation. It's not a great leap from there to just format it. One can also say that it is not a huge leap for compiler to do the same. Of course all those tool can share a lot of implementation and often are used together, but I think there is a value in keeping unrelated functionality separately available. UNIX-way ftw.
Re: Static Analysis Tooling / Effective D
On 1/21/2014 12:54 AM, Dicebot wrote: On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote: Automated source code formatting would be nice (and it's not as easy as it looks). It has nothing to do with static analysis. Coverity (a static analyzer) does checks based on whitespace indentation. It's not a great leap from there to just format it.
Re: Static Analysis Tooling / Effective D
On 1/20/2014 8:34 PM, Brian Schott wrote:
I've checked in code to the DScanner project that gives it some basic static
analysis capabilities. When run with the --styleCheck option, it will warn about
a few things like empty declarations, implicit string concatenation, classes
with lowercase_names, catching Exception, and a few other things.
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?
Sooner or later, you're going to want to add data flow analysis. DFA will open
up a universe of useful checks it can do. For example, you can do things like:
class C { int x; }
C foo() { return null; }
int bar(int i) {
auto c = i ? foo() : new C();
return c.x;// error, path to null dereference
}
and a heckuva lot more.
For a laundry list, google Coverity and look at the bug reports it generates.
Many of the reports have no meaning for D, as D has defined them out of
existence, but there are plenty of others.
Re: Static Analysis Tooling / Effective D
On 1/21/2014 12:58 AM, Dicebot wrote: That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally? Since we have user defined attributes, I don't see how anything further needs to be added to the language.
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 09:30:45 UTC, Walter Bright wrote: On 1/21/2014 12:58 AM, Dicebot wrote: That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally? Since we have user defined attributes, I don't see how anything further needs to be added to the language. See reserved namespace reference. It does not need any special support from the language itself but some support from spec that will ensure that those attributes won't conflict with user code and other tools will be helpful. Probably even in form of guideline, not a rule.
Re: Static Analysis Tooling / Effective D
On 2014-01-21 10:33, Dicebot wrote: See reserved namespace reference. It does not need any special support from the language itself but some support from spec that will ensure that those attributes won't conflict with user code and other tools will be helpful. Probably even in form of guideline, not a rule. The answer to this is usually that each tool should use its own attributes and that fully qualified names should properly disambiguate the attributes. Although, in this case it might be asking a bit too much for a tool to be able to properly figure out fully qualified names of symbol names. -- /Jacob Carlborg
Re: Static Analysis Tooling / Effective D
On 2014-01-21 05:34, Brian Schott wrote: I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching Exception, and a few other things. 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? Have a look at the Clang static analyzer as well. How accurate source information is kept? Xcode can, with the help of Clang, graphically show the flow path. -- /Jacob Carlborg
Re: Static Analysis Tooling / Effective D
Walter Bright wrote in message news:lbl9ha$i85$1...@digitalmars.com... Automated source code formatting would be nice (and it's not as easy as it looks). That would be great, we could run it on the generated ddmd source and I wouldn't have to fix all the remaining formatting bugs!
Re: Static Analysis Tooling / Effective D
Walter Bright: Coverity (a static analyzer) does checks based on whitespace indentation. This is good to have. Perhaps splitting the compiler in some parts could help people create such tools. Bye, bearophile
Re: Static Analysis Tooling / Effective D
On 1/21/2014 1:33 AM, Dicebot wrote: See reserved namespace reference. It does not need any special support from the language itself but some support from spec that will ensure that those attributes won't conflict with user code and other tools will be helpful. Probably even in form of guideline, not a rule. This is quite overengineering to put such in the spec. @coverity_warnings should do fine (i.e. prefix with your tool name). It's not any harder than coming up with names for your third party library.
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 20:26:57 UTC, Walter Bright wrote: On 1/21/2014 1:33 AM, Dicebot wrote: See reserved namespace reference. It does not need any special support from the language itself but some support from spec that will ensure that those attributes won't conflict with user code and other tools will be helpful. Probably even in form of guideline, not a rule. This is quite overengineering to put such in the spec. @coverity_warnings should do fine (i.e. prefix with your tool name). It's not any harder than coming up with names for your third party library. 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.
Re: Static Analysis Tooling / Effective D
On 1/21/2014 1:07 PM, Brian Schott wrote: On Tuesday, 21 January 2014 at 20:26:57 UTC, Walter Bright wrote: @coverity_warnings should do fine (i.e. prefix with your tool name). It's not any harder than coming up with names for your third party library. 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. The trouble is if you start doing that, you end up in an endless ratrace of adding ever more standard names. If you're going to use a static checker, it doesn't seem to me to be a big burden to provide an import for it.
Static Analysis Tooling / Effective D
I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching Exception, and a few other things. 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?
Re: Static Analysis Tooling / Effective D
It would be perfect have plugin for any Text Editor like Sublime
Re: Static Analysis Tooling / Effective D
On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote: I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching Exception, and a few other things. 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? I don't have any D specific errors that I keep repeating. I use SonarQube at work with Java. Here is a list of some of the rules that I use: https://github.com/SonarSource/sonar-java/tree/master/java-checks/src/main/java/org/sonar/java/checks
