> yet to be proven that is safer than C/C++ with various tools. What "various tools"? Buffer overruns were old-hat decades ago. Impossible in Pascal in 1970, i

> yet to be proven that is safer than C/C++ with various tools. What "various tools"? Buffer overruns were old-hat decades ago. Impossible in Pascal in 1970, impossible in ALGOL-60 years before that. If the C/C++ tools to protect against buffer overruns in 2020 are worse than the technology of sixty years ago, how much longer do you suggest we wait? > Because one issue This isn't the first buffer overrun issue. This isn't the first buffer overrun issue in 2020. PHP has had a buffer overflow which could leak data or crash. IBM DB2 has had a buffer overflow which could allow an attacker to gain privileges. macOS and all iPad/WatchOS and iTunes for Windows have had buffer overruns leading to arbitrary code execution. Samsung Galaxy S10 has. QEMU has. pppd has. SQUID has. CA Nimsoft has arbitrary code execution buffer overflow. PHP Multibyte string handling has. Emerson OpenEnterprise SCADA, libmysofa, OpenJPG, mRuby, libMing, Cisco Unified Contact Center, Honor smartphones, QEMU iSCSI handling, Intel Graphics Drivers, Adobe Reader arbitrary code execution (Again!) just look https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer and that's only the CVE disclosed ones. > If you think that's possible why no-one is actually doing it? It's cheaper and more profitable not to bother.