It is funny that you claim C is unsafer because "it has pointers". The opposite is true: Java and C# have practically only pointers (for non-native types). The most common error in Java is probably the Null Pointer Exception (cf. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). The second most common error is probably holding hidden references to unused objects (e.g. closed Dialogues are not disposed of) which therefore cannot be released, leading to long-running programs with an ever-growing memory foot print.

There are two basic mechanisms which make C# and Java safer, and safer in two different ways:

• Garbage collection makes it less likely that the program attempts to access discarded objects. This makes the program less likely to terminate unexpectedly. As opposed to C, Java and C# by default allocate non-native data dynamically. This makes the program logic actually more complex, but the built-in garbage collection -- at a cost -- takes over the hard part.

Recent C++' smart pointers make that job easier for programmers.

• Java and C# compile to an intermediate code which is interpreted/executed by an elaborate run time. This adds a level of security because the run time can detect illicit activities of a program. Even if the program is coded insecurely (which is possible in both languages), the respective run time in theory prevents "breaking out" into the system.
  The run time does not protect against e.g. attempted buffer overruns, but in theory does not allow exploits of such programs. With C and C++, by contrast, the programmer has to code securely in order to prevent exploits. This is usually not achieved right away but needs reviews and iterations.

It is worth noting though that the elaborate run time is also a security risk. It appears to me that Oracle is updating the JVM every couple of weeks because of newly discovered safety issues. It is, of course, much harder to verify the JVM than a single program.

The safety of an elaborate run time is therefore ambiguous and to a degree deceiving: Your average C program can, with reviews and iterations, be made reasonably secure. Your average Java program is only as secure as the JVM; that is, not really. Never.

The article about gets() that you link to reflects historical library decisions which would be made differently today, not the core language.

It is funny that you claim C is unsafer because "it has pointers". The opposite is true: Java and C# have practically only pointers (for non-native types). The most common error in Java is probably the Null Pointer Exception (cf. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). The second most common error is probably holding hidden references to unused objects (e.g. closed Dialogues are not disposed of) which therefore cannot be released, leading to an ever-growing memory foot print of long-running programs.

There are two basic mechanisms which make C# and Java safer, and safer in two different ways:

• Garbage collection makes it less likely that the program attempts to access discarded objects. This makes the program less likely to terminate unexpectedly. As opposed to C, Java and C# by default allocate non-native data dynamically. This makes the program logic actually more complex, but the built-in garbage collection -- at a cost -- takes over the hard part.

  Recent C++' smart pointers make that job easier for programmers.

• Java and C# compile to an intermediate code which is interpreted/executed by an elaborate run time. This adds a level of security because the run time can detect illicit activities of a program. Even if the program is coded insecurely (which is possible in both languages), the respective run time in theory prevents "breaking out" into the system.
  The run time does not protect against e.g. attempted buffer overruns, but in theory does not allow exploits of such programs. With C and C++, by contrast, the programmer has to code securely in order to prevent exploits. This is usually not achieved right away but needs reviews and iterations.

It is worth noting though that the elaborate run time is also a security risk. It appears to me that Oracle is updating the JVM every couple of weeks because of newly discovered safety issues. Due to its complexity, the JVM is much harder to verify than most specific programs.

The safety of an elaborate run time is therefore ambiguous and to a degree deceiving: Your average C program can, with reviews and iterations, be made reasonably secure. Your average Java program is only as secure as the JVM; that is, not really. Never.

The article about gets() that you link to reflects historical library decisions which would be made differently today, not the core language.

It is funny that you claim C is unsafer because "it has pointers". The opposite is true: Java and C# have practically only pointers (for non-native types). The most common error in Java is probably the Null Pointer Exception (cf. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). The second most common error is probably holding hidden references to unused objects (e.g. closed Dialogues are not disposed of) which therefore cannot be released, leading to long-running programs with an ever-growing memory foot print.

What makes C# and Java safer is the garbage collection. Recent C++' smart pointers add a great deal of safety to the language in this respect.

The article about gets() that you link to reflects historical library decisions which would be made differently today, not the core language.

It is funny that you claim C is unsafer because "it has pointers". The opposite is true: Java and C# have practically only pointers (for non-native types). The most common error in Java is probably the Null Pointer Exception (cf. https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). The second most common error is probably holding hidden references to unused objects (e.g. closed Dialogues are not disposed of) which therefore cannot be released, leading to long-running programs with an ever-growing memory foot print.

There are two basic mechanisms which make C# and Java safer, and safer in two different ways:

• Garbage collection makes it less likely that the program attempts to access discarded objects. This makes the program less likely to terminate unexpectedly. As opposed to C, Java and C# by default allocate non-native data dynamically. This makes the program logic actually more complex, but the built-in garbage collection -- at a cost -- takes over the hard part.

Recent C++' smart pointers make that job easier for programmers.

• Java and C# compile to an intermediate code which is interpreted/executed by an elaborate run time. This adds a level of security because the run time can detect illicit activities of a program. Even if the program is coded insecurely (which is possible in both languages), the respective run time in theory prevents "breaking out" into the system.
  The run time does not protect against e.g. attempted buffer overruns, but in theory does not allow exploits of such programs. With C and C++, by contrast, the programmer has to code securely in order to prevent exploits. This is usually not achieved right away but needs reviews and iterations.

It is worth noting though that the elaborate run time is also a security risk. It appears to me that Oracle is updating the JVM every couple of weeks because of newly discovered safety issues. It is, of course, much harder to verify the JVM than a single program.

The safety of an elaborate run time is therefore ambiguous and to a degree deceiving: Your average C program can, with reviews and iterations, be made reasonably secure. Your average Java program is only as secure as the JVM; that is, not really. Never.

The article about gets() that you link to reflects historical library decisions which would be made differently today, not the core language.