Run Microsoft Analyzer over dmd source code

Don nospam at nospam.com
Mon Aug 8 12:45:51 PDT 2011


KennyTM~ wrote:
> On Aug 7, 11 22:23, Vladimir Panteleev wrote:
>> On Sun, 07 Aug 2011 13:29:20 +0300, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> It's less complex (!) if you are not trying to make a working dmd. It
>>> just needs to compile.
>>
>> OK, that wasn't actually too bad.
>> https://github.com/CyberShadow/dmd/tree/compile-on-vs10
>>
>> 2979 warnings with code analysis with the "Microsoft Minimum Recommended
>> Rules" ruleset.
>> http://dump.thecybershadow.net/2e0571641194d945869a1b12b29aacdc/DMD.log
>>
>> I'll see if I can get it in a more readable format (something like the
>> HTML files clang's scan-build outputs).
>>
> 
> Just at a glance, half of them are false positive, or is arguably safe:
> 
> 1. 382 (13%) of them are C4996 (use those Microsoft _s functions)
> 2. 401 (13%) of them are C4068 (unknown pragma)
> 3. 505 (17%) of them are C6328 (passing 'signed char' to the ctype 
> functions)
> 4. 67 (2%) of them are C6239 (true && something) or C6240 (something && 
> true) - many of them are of them (!I16 && stuff), so that's legacy code 
> for 16-bit platform??
> 5. 37 (1%) of them are C6255 (using alloca) or C6263 (using alloca in a 
> loop).
> 6. 56 (2%) of them are C4305 or C4309 (double -> float)
> 
> And 37% of them can be caught trivially with some -Wall flag.
> 
> 4. 262 (9%) of them are C4244 (stuff like int64 -> int32)
> 5. 415 (14%) of them are C4018 (signed/unsigned comparison)

I noticed some pretty annoying behaviour:
When s is signed and u is unsigned:
   if (s >= 0 && s < u) ...
generates a 'signed/unsigned comparison' error.
So there's a lot of false positives in there.

> 6. 157 (5%) of them are C4101 (unused locals)
> 7. 50 (2%) of them are C4102 (unused labels)
> 8. 212 (7%) of them are C6246 or C6244 or C4258 (local variable name 
> hiding outer scope)
> 9. 8 (0.3%) of them are C4390 ('if(stuff);')
> 
> The really interesting things:
> 
> 8. 117 (4%) of them are C6211 (leak on exception) - but a bigger problem 
> is DMD is using too much memory even without leaking.

I don't think anything in DMD ever throws an exception. Those are all 
false positives in practice (but would become real bugs if DMD ever 
starts using exceptions).

> 9. 34 (1%) of them are C6001 (using uninitialized memory)
I think these are false positives too. The ones I saw were of the form:
When p is a pointer,
  assert(p);
  y = p->x; // error: p is uninitialized

> 10. 125 (4%) of them are C6011 (NULL dereferencing)
> 11. 6 (0.2%) of them are C6386 and 17 (0.6%) of them are C6385 (buffer 
> overrun)
This looks more promising than clang.


More information about the Digitalmars-d mailing list