Programming in C must be banned

http://arstechnica.com/security/2016/08/code-dumped-online-came-from-omnipotent-nsa-tied-hacking-group/
https://xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/
Once again, a buffer overflow has lead to new vulnerabilities in C land. This time all pre-2013 Cisco routers are affected.

It does indeed feel there is a gaping hole in our software stack as these buffer overflows are only increasing in rapidity. It is time we take a serious look at the epidemic of exploits in C land, and begin to implement real solutions; they are out there.

It’s hard to deny that easy access to stack, especially unpriveleged access, plays a serious role in creating computer crime. How many buffer overflows happen in languages with access checks on stacks? How many buffer overflows are discovered in the Ada each year? None. How many in Haskell? None. How many in Java? None. The list could go on. And yet, mass exploitation in the C-land continue to increase. There is certainly a correlation. But there are other important causes at play as well: the language is an ill-designed clusterfuck of hacks upon hacks.

Of course, mass buffer overflows are only one indication of the security nightmare that plagues the language — the whole language is built on unsafe and insecure code. In the C-land, memory rules are much more lax than that of other popular languages, on par with the assembly and lacking even basic safety features: unless explictly requested by the programmer.

Nearly 70% pre-2013 routers are Cisco and are vulnerable to being hacked during the %CurrentYear%.
https://gigaom.com/2013/02/27/chart-cisco-owns-the-switching-and-routing-world/

These are a only a few of the indicators of what may feed into the hopelessness and despair that causes so much distrust in C and its derivatives. The bugs cost real money and real work-hours to be wasted on correcting and debugging the garbage that was compiled by compilers which don't value anything but speed and memory use..

>>80
The only reason we still have jailbreaks for phones, cracks for games and torrents for tv shows is because of C.
You'd rather have it so all the vendors could team up and lock down all of their devices in the name of "security"? Make it so that it's impossible to find a device with an unlocked bootloader on the market?

>>17
vulnerabilities exist even if you are using a "safe" language/platform

>>82
stop talking to yourself

>>81
This is actually what I want. This way, we can actually support companies and initiatives the produce hardware that respect the users' freedom.

>>81
You can still crack software, and capture tv even if their designs were bug free, because if you can run or play something, you can modify it to do anything you want (for software cracks), or decrypt the transmission (because your player has to be able to play it). An absolutely secure bootloader only means that modifying it would be prohibitively expensive as it would require tools that are currently not yet available cheaply, however you could run anything that runs on that hard on more Free hardware as long as its compatible - that's how emulation works, and given the right hardware tools there's nothing preventing anyone from extracting any hardware secrets or keys, thus breaking down their entire chain of trust.

Secure software design would not endanger cracks or capturing tv shows, but it might make them a lot more expensive. It would also make all those consoles and smartphones worth throwing in the trash because you wouldn't be able to open them up, as the hardware only obeys their makers, but you could run anything that runs on them on more open hardware if you could extract their secrets.

>>84
The pro-DRM bastards want control over your brain. They want to feed you adverts and manipulate your mind directly. They would make you experience sensations of physical pain for even thinking of anything subversive if they could. Direct neural interface? DO NOT WANT!

>>85
We're not there yet Cudder and like hell we'll let it get there, fuck them. Learn to make your own things and you'll be fine.

C-dder is all talk and no action.

STOP BULLYING MY WAIFU

>>85
Paranoid much, Cudder? Embrace the cyberpunk dystopia already. Your daughter could be the next Shakugan no Shana!

>>85
By using a computer in any way you need accept that someone else may be able to see what you are doing. By nature it is an insecure medium.

If you want security, do it analog

>>91
What if your computer is disconnected from the internet?

>>89
I want to marry Cudder's daughter and fight for freedom and privacy together!

>>90
Computers are equally insecure as paper is insecure. By that standard, all things are inherently insecure.

http://ziglang.org/

okay stop worrying, we can just use this instead

>>93

tfw the newspaper keeps phoning home

At the end of the day, all you're trying to do is build safe abstractions upon an unsafe machine (in this case a computer with things like pointers, unseparated address spaces, overflows and whatnot).
The point is that:
A. a lot of computing environments (CEs) (a HLL in this case) use C as a bottom layer and it could be argued that since the CE internally uses C, then the CE is similarly insecure
OR
B. that you don't need the HLL at all, since you can write safe abstractions in C itself

Soon time for dubs!

>>97
oh fuck off

_{(this space intentionally says fuck you)}

_{(this space intentionally says fuck you)}

Dubsplosion!

>>96

B. that you don't need the HLL at all, since you can write safe abstractions in C itself

You don't need C at all because x86 assembly has better error handling, better primitives (e.g. SIMD), and better macros. I'm not even joking. It really is better.

and better macros

Wrong.

x86 assembly is non-portable

>>102
Recommended daily iron intake.

>>103,104
Shame on you.

Are x86 macros even portable between different assemblers?

>>106
No, they're assembler specific. So with GNU Assembler, the macros are actually portable across the different assembly languages. Same macros for x86 and arm for example.

>>107
Asm by itself is not portable so the macros don't change anything. Also, if you need asm macros FASM is far superior to GAS.

>>107
GAS is trash though.

x86 optimizations are non-portable even among x86 platforms.

_{(this space left intentionally x86-incompatible)}

>>107-109
GAS the C kikes with assembly.

>>96
Another false dilemma fallacy. You want us to choose between C as a bottom layer OR C for everything, but there's a third choice: C for nothing.

Most CPU architectures weren't designed with C in mind. They were thinking about other language compilers, not C compilers.

>>113
Where exactly do I get an ``other language compiler" that doesn't produce bloated binaries?

>>114
MSVC

>>17
Save this post and read it 10 years later.

All this security is going to turn society into a bureaucratic, authoritarian, dystopian prison. We're basically locking ourselves up, and these masses of sheeple are blindly charging full speed into it without ever questioning what they're losing. As long as they feel safe and secure they'll sacrifice anything.

It’s hard to deny that being able to think, plays a serious role in creating computer crime.

FTFY.

"If freedom is outlawed, only outlaws will have freedom."

"The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants."

>>116
Security is for the owner of the computer.

Letting C into your computer is like letting terrorists into your country. C ``empowers'' real terrorists to damage physical equipment, like Stuxnet, create viruses and ransomware, and spy on people. They might be able to do it without C, but their job would be a lot harder.

The governments use exploited C programs as an excuse for why they need more laws, bigger agencies, hardware backdoors, and all of this ``bureaucratic, authoritarian, dystopian'' bullshit.

Cee and Sepples will prevent skynet from being functional, debugging Sepples code cannot be practically automated.

>>117

Governments are the biggest terrorists. Especially Russian government, led by KGB officer Putin.

>>117
7/10.