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..

Its 2016, people still use C rationale excuse to explain away deficiencies in C: and C committee is stuck in the past.
https://www.lysator.liu.se/c/rat/a.html

How many buffer overflows are discovered in the Ada each year?

https://imgs.xkcd.com/comics/haskell.png

Btw, ignoring the obvious troll, if you had any clue about the internal workings of a core switch, you couldn't name one proglang in which to implement code for it besides C. Linespeed!

forgot to sage, here

JACKSON 5 GET

>>3
Assembly, or a language that has control on how it generates its own assembly, like most Common Lisps.

>>3
Compile to LLVM IR and make it self hosting.

I think people's minds are damaged by thinking about a layer of C between their program and the hardware even if they're not writing it in C.

Knowing about the low level is important, but you should be thinking about the CPU architecture instead of C.

Even decompiling programs is more difficult when you use C or C-like languages.

>>3
no you fucking moron. > durr you can only write it in C
this article proves you cannot write it in C even if you wanted to

I don't like how people always spout that C is "close to the hardware". You can't even do a fucking arithmetic right shift in C, let alone get access any of the cpu caches or cores.
C is only "close to the hardware" if you're programming for a PDP-11.

http://ai.neocities.org/forthagi.txt

>>10

arithmetic right shift in C

main(int argc, char *argv[]) {
argc /= 64;
return 0;
}
produces a sarl instruction on GCC with optimizations turned off.

access [..] caches

I guess you're not supposed to. 'cache' is french for 'hide', after all.

>>10
exactly

doesn't support arbitrary jumps without saving context

No access to the carry bit always rustled my jimmies.

C doesn't even have a standard for inline assembly language, and many projects resort to a ton of 0xXX literal bytes. It's complete garbage.

>>14
you can make an abstract_typedef_struct_factory in C to handle that like the cool kids do

>>12
Fuck off back to France!

Only the corporate tyranny wants to ban "insecure" things. Because then the masses cannot revolt. Imagine a world in which everything is "perfectly secure". You'd be living in a prison. Some big faceless entity will have decided everything about what you can and cannot do. If you don't like how something works? Sorry, that "perfect security" means you can't change it. It doesn't even have to be DRM. They'll force adverts into your brain and it'll be illegal and impossible to get away from it. This is like 1984, but much worse.

So the fact that things get hacked regularly is good. It means that there is still freedom. They don't call them "jailbreaks" for nothing...

If you are a proponent of "safer" languages you are basically advocating for "guilty until proven innocent" and want to turn programmers into mindless drones by restraining them to do exactly what you want. FUCK THAT SHIT.

"Insecurity is freedom."
"Those who give up freedom for security deserve neither."

>>1
The C programming language does not offer any kind of easy access to any stack. The problem lies in your implementation and your inability to chose ``safe'' compilers.
If you made use of a compiler for Haskell or Java that allowed for access to the stack then you would have the exact same problem.

Anyhow, it is well known that all popular routers are filled with NSA backdoors, you can make your own of much higher quality with less than $200. http://arstechnica.com/gadgets/2016/04/the-ars-guide-to-building-a-linux-router-from-scratch/

>>17
hey Cudder, I see where you're comming from and I like that old-school hacker mindset but there's just one problem with it: the landscape has changed. in the 90s/early 00s, insecure code provided countless relatively harmless lulz but as time went on, it became abused by NSA, other governments, corporate advertisers, common thieves and other people you don't want on your computer.

the solution to jailbreaking isn't more buffer overflows. it's more open-by-design devices. the same goes for crypto: bad crypto might be cool when you're breaking a DRM but it's less cool when someone can spy on your communications. security is a technical issue, openness is a cultural one.

I think we can have both secure software which gives us privacy and the ability to install, modify and hack anything we want on our devices. hell, given the stupidity of webdev monkeys means we can be able to not only have those things but also to have oldschool hacker lulz while the critical (not web-based) systems will be secure.

>>18

The C programming language does not offer any kind of easy access to any stack.

..says the nigger who has never C enough. I guess taking the address of a stack-allocated item is just some fantasy to you.

>>17
Go fuck yourself with a shotgun, you fucking ignorant malignancy. You don't know what the fuck you're talking about with the shit you drool on about "insecure" things. You don't even warrant a response beginning to describe the myriad places where you go into fuck-off land.

Just die already, you worthless piece of shit.

>>20

..says the nigger who has never C enough

Is that supposed to be a valid sentence?

I guess taking the address of a stack-allocated item is just some fantasy to you.

While your compiler might allow you to do that the C standard says nothing about it.

I far that you misunderstood my post due to your inability to think out of the box.

Go fuck yourself with a shotgun, you fucking ignorant malignancy. You don't know what the fuck you're talking about with the shit you drool on about "insecure" things. You don't even warrant a response beginning to describe the myriad places where you go into fuck-off land.
Just die already, you worthless piece of shit.

This is the first and the last time I warn you: Don't you fucking bully Cudder or I will come to your house and rape you using a snake with retarded looking eyes.

Cudder is a corporate tranny!

>>18
There is entire programming model that is based on easy stack access. Thats why -fstack-protector-all exists.
https://en.wikipedia.org/wiki/Return-oriented_programming

>>10

C is only "close to the hardware" if you're programming for a PDP-11.

How do you access the PDP-11's flags from C? Multi-precision arithmetic is pretty simple on the PDP-11.

>>12
Now do it on a way that doesn't depend on the compiler.
Even JAVA has >> and >>>.

They are `close to the machine' in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers, and they rely on library routines for input-output and other interactions with an operating system.
https://www.bell-labs.com/usr/dmr/www/chist.html

>>24
Wow, it looks like I was wrong. C was trash from the very beginning.

>>25

Now do it on a way that doesn't depend on the compiler.

I guess you are right. I could now try to create a portable arith shift using unions (signed and unsigned types have the same size and 2s complement can be emulated using unsigned types only in C) and other binary ops but what's the point? The behaviour is the same as signed division. Arithmetic shifting has always been an optimization for divisions and most of the time you want binary shifting anyway. If you could give me an example of when you actually need arith. shifts (and not premature optimizations of divs), I would be thankful.
I would be more concerned that C doesn't have native binary rotations but then again there are portable workarounds to this.

Even JAVA has >> and >>>.

Yeah, and no unsigned types, which would have prevented the stupid additional operator here.

>>28
"C is close to the hardware."
"No it isn't, C doesn't even provide this simple binary operation supported by every available architecture since the beginning of time."
"Why would you want that."

Classic.

>>28

Arithmetic shifting has always been an optimization for divisions

I see what you mean but there's other stuff you can do with it as well

>>28
That's the same excuse Haskell programmers use.

>>29

"C is close to the hardware."

Nice misquoting me. I never even said anything remotely similar.

"Why would you want that."
I see what you mean but there's other stuff you can do with it as well

Again, providing a reasonable use-case for arith shifts in HLLs (anything above assembler) would be nice. But since you want arith shifts in C (and possibly other HLLs, too), why not also add all these weird x86 ASCII/BCD ops, too? Oh yeah right: because you don't need them. Prove me wrong or shut it.
C is confusing enough, adding even more undefined behaviour in the form of weird binary ops isn't going to help.

None of you fucknuggets who are saying C is secure, or that asm-level operations shouldn't be exposed are worthy of gracing even a shithole such as /prog/. Y'all need some McCarthy in yo life.

>>33
One word: DYNAMIC SCOPING

>>33
And exactly none of said fucknuggets were around for the 8-bit home computer era where assembly language was necessary, and taught you how to use bit tricks and find ways to slam into code to save space. A bunch of uneducated millenial nigger hipsters in this thread, I tells ya.

>>35
This. Start low-level. Most /prog/rammers today can't even sort an array if their language don't have .sort() included.

Learn you a Commodore 64 for great good, so you can control your hardware again.

: inc $d020
jmp :-

If you want to depose C you have to provide a replacement that gives you just as much power.

What does your C replacement look like?

It is the year of 2016, if thou are not writing programs in the ATS language so thou truly are a moron!