The very fact that NPE exists, in a language which doesn't have pointers, running on a JVM that doesn't have pointers, is evidence that the entire model of "doe

The very fact that NPE exists, in a language which doesn't have pointers, running on a JVM that doesn't have pointers, is evidence that the entire model of "doesn't have pointers" is a sham. The reality of computer architecture is that data resides in memory, memory is an array of bytes, and bytes have addresses (i.e., pointers) and denying this fact is impossible. Even in a pure pointerless system like Java. And if there are pointers in the system, somewhere, anywhere, they are exploitable. Remote code execution vulnerabilities in C are less a feature of the language syntax and mostly due to the abysmally poor C library, which is regrettably part of "C The Language" - but no one forces you to use it - there are better libraries. Also, it's an artifact of implementation - just as Java's supposed immunity is an artifact of implementation, not an inherent feature of the language syntax. Case in point http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulnerability/7033/oracle-java-se-remote-code-execution-vulnerability-cve20152590 http://www.trendmicro.com/vinfo/us/threat-encyclopedia/vulne... As for RCEs in C code - these would be easily avoided if the implementation used two separate stacks - one for function parameters, and one for return addresses. If user code can only overwrite passive data, stack smashing attacks would be totally ineffective. Again - there's nothing in the C language specification that dictates or defines this particular vulnerability. It is solely an internal implementation decision.