1

Is there a good reason why this code compiles without warning (and crashes when run) with Visual C++ 2010:

int a = *((int*)nullptr);

Static analysis should conclude that it will crash, right?

David
  • 3,324
  • 2
  • 27
  • 31
Paul Jurczak
  • 7,008
  • 3
  • 47
  • 72

2 Answers2

6

Should this use of nullptr produce a compiler error?

No.

Dereferencing a null pointer results in undefined behavior, but no diagnostic is required.

Static analysis should conclude that it will crash, right?

It might. It doesn't have to. It would certainly be nice if a warning was issued. A dedicated static analysis tool (Klocwork, for example) would probably issue a warning.

James McNellis
  • 348,265
  • 75
  • 913
  • 977
  • 4
    When doing "normal" building, you might want it to run as fast as possible (unless you enjoy sword fighting), so skipping trivial static analysis (who purposefully derefs a nullptr, after all) can help. – Fred Nurk Jan 28 '11 at 00:58
  • @Fred: That is one reason, yes. Another reason is that most compilers have rather limited static analysis exposed to users via diagnostics. Dedicated static analysis tools are much more thorough (and take much, much longer to run, depending on what types of errors you are looking for). – James McNellis Jan 28 '11 at 01:11
  • 1
    @Fred Nurk: +1 for the XKCD reference. `:)` – Matteo Italia Jan 28 '11 at 01:12
  • such nullptr's can be trivial for the compiler to detect yet hard for the programmer when they're template parameters (particularly inferred template parameters). Such an analysis could thus catch more that just "obvious" cases. Similarly, inlined methods or long methods in which nullptr declaration is far from pointer use may be trivially verified in the compiler yet hard to spot. – Eamon Nerbonne Feb 21 '11 at 14:31
3

Yes, static analysis would show this to always crash. However, this would require the compiler to actually perform this static analysis. Most compilers do not do this (at least none I know of).

So the question is: Why don't C/C++ compilers do more static type checking.

The reason the compiler does not do this is mostly: tradition, and a philosophy of making the compiler as simple as possible.

C (and to a lesser degree C++) were created in an environment where computing power was fairly expensive, and where ease of writing a compiler was important (because there were many different HW architectures).

Since static typechecking analysis will both make a compiler harder to write, and make it compile more slowly, it was not felt at the time to be a priority. Thus most compilers don't have it.

Other languages (e.g.) Java make different tradeoffs, and thus in Java many things are illegal that are allowed in C (e.g. unreachable code is a compile-time error in Java; in C most compilers don't even warn). This really boils down to philosophy.

BTW, note that you can get static typechecking in C if you want it - there are several tools available, e.g. lint (ancient), or see What open source C++ static analysis tools are available? .

Community
  • 1
  • 1
sleske
  • 81,358
  • 34
  • 189
  • 227
  • 1
    "Static [analysis] will both make a compiler harder to write, and make it compile more slowly," and often not work in the (complex) situations you really, really wish it would. (Detecting nullptr is analysis instead of typechecking, for example.) – Fred Nurk Jan 28 '11 at 01:21
  • @Fred: Oops, of course I meant "static analysis", not "static typechecking". Thanks, fixed. – sleske Jan 28 '11 at 22:27