Satan is the father of lies

These C liars constantly claim that the work of other people came from C and Bell Labs hackers. Who would do that other than Satan and his servants?

They are so deluded by Satan that they believe the idea of variables and ASCII text came from C.

Okay, what y'all youngins need to understand is what programming looked like before C, and what it looked like with C.

What if, rather than manually typing in memory addresses, you could store stuff in variables that the rest of the program can access BY ENGLISH NAME? Or, when you need to, store memory addresses in variables, which you could still access by name? What if you automated all this, so the program itself allocated, read, and wrote memory addresses to the variables, so no programmer would ever need to do it themselves?

THIS is the level we're working at, OP. For some newage twirp to say it's a "fundamentally flawed language and has many errors" is just mentally painful. By errors he means "It doesn't do this thing we have space to run now, it not doing something that other things do is a FLAW and an ERROR"
We went from "Manually type in the address of the thing you want, or maybe offset stuff from an address if you really want, either way you're keeping a spreadsheet full of hex codes on your desk if you like it or not" to "Lol here it all is, named and everything, no need to know the address, you can simply copy the address of a variable to another variable and use the second to access the first, if something out of scope wants direct access to the first, just give it the second and it can do what the fuck it wants, go wild with math if you like but don't be a twat and TRY to keep track of where everything is"
Do you even begin to understand how much of a DREAM this shit was to programmers? It's all these halfwit newbies that think the compiler should keep everything safe for them no matter what that look at C and go "Now, this language so utterly pure and without clutter, it's FUNDAMENTALLY FLAWED and HAS MANY ERRORS because IT'S NOT FULL OF SHIT THAT DOES EVERYTHING FOR ME, IT DOESN'T GET IN THE WAY, IT DOESN'T STOP ME FROM DOING WHAT I WANT, IT EXPECTS ME TO KNOW WHAT I'M DOING, IT'S SO GARBAGE BECAUSE I'M TO FUCKING DUMB TO FOLLOW THE SIMPLEST RULEBOOK IN PROGRAMMING"

YES YOU HAVE TO KEEP A VAGUE IDEA OF HOW YOUR MEMORY WORKS, BUT C DOES SO BLOODY MUCH FOR YOU THAT ANYTHING MORE IT LITERALLY "BABBIE FIRST DRAG AND DROP HOCKEY GAME"
IT'S NOT EVEN MANAGING MEMORY, IT'S SITTING IN YOUR COMFY OFFICE TELLING THE PR GUY TO GET RID OF DEPARTMENTS YOU DON'T NEED ANYMORE, AND ADDRESSING EMPLOYEES BY THEIR BADGE NUMBER, NOT THEIR NAME, GENDER, WHAT OR WHO THEY ARE, JUST A SIMPLE NUMBER, AND PEOPLE STILL MANAGE TO SCREW IT ALL UP AND SAY "IT'S TOO HARD"

>>40
dubs are scarce these days

>>19
you're pointing to software written in C (SQL implementations, deserialization libraries that link to compiled C, etc.) as evidence that the memory-safe languages are unsafe too.

there will never be a way to ensure programmers don't create security exploits by making logic errors. finding these kinds of logic errors means being very familiar with the code. by contrast, buffer overflows and such all have a very specific pattern that you can look for. if the programmer couldn't find/fix the error in his own code, what hope does a security consultant have? if it's just obvious errors, then he's a shit progammer (how does he do the rest of his work?). either way I don't see the need.

in (very) high level languages, proper security becomes just another standard that the organization uses. there really should be only ONE way to ever do "forgot password" for example. aside from crypto and buffer overflows, security is mostly common sense.

as for the low level multimedia stuff and kernels, I think a good compromise is C++ with smart pointers, but even then only for hot loops.

>>42

you're pointing to software written in C (SQL implementations, deserialization libraries that link to compiled C, etc.) as evidence that the memory-safe languages are unsafe too.

but SQL injections have nothing to do with C or memory, they'd be the same regardless of language used for the interpreter. same goes for deserialization and OS command injection. the issue is that user-supplied data is being inserted raw into what is essentially code. you could maybe argue that this is a type safety issue but even the fancy typefag research languages haven't solved that problem yet (because they'd rather focus on academic shit than on anything practical).

if the programmer couldn't find/fix the error in his own code, what hope does a security consultant have?

from experience? a lot of hope. programmers usually think in terms of intended use and unintentional error, not in terms of malicious misuse.

aside from crypto and buffer overflows, security is mostly common sense.

interfacing between different high-level languages is not common sense (and that's the source of deserialization errors, SQLi, XSS). race conditions are not common sense. any sort of complex interaction with untrusted input is not common sense. communication protocols are not common sense. also, given how common the social engineering attacks are - even common sense isn't that common.

<- dubs, check them

>>19,31,43
You're unfamiliar with the idea of programming Satan's computer.

From the 50s to the 80s, when ``The result should be a considerable reduction in the training required to program, as well as in the time consumed in writing programs and eliminating their errors.'' was something programmers wanted, the problem was like >>30 said. That was Murphy's computer, preventing accidental bugs and damage by making programming easier. When programming becomes easier, bugs become harder to do accidentally. Programmers wanted this whether they were making the software for themselves or someone else. Users wanted reliable programs that worked.

But now we are in a different world: Satan's computer. This was brought about by Satanic hacks like the Morris worm. Now there are hacks that nobody would dream of doing on Murphy's computer. The problems are not caused by accidental bugs that hinder productivity and damage data, they are intentional malicious hacks.

If we have so many solutions, why aren't C programmers using them? They don't want solutions. They use C because they want programming to be bad forever. They want every computer to be Satan's computer forever.

>>42

if the programmer couldn't find/fix the error in his own code, what hope does a security consultant have? if it's just obvious errors, then he's a shit progammer (how does he do the rest of his work?). either way I don't see the need.

That sounds like the Emperor's New Clothes again. You're saying these programmers are ``unfit for their positions, stupid, or incompetent''. The Bell Labs ``weavers'' made a lot of software with buffer overflows and a language that makes buffer overflows easier. C hackers say people used hex addresses before C brought English variables into programming, but that's a huge lie. C hackers are the townspeople marveling at how wonderful the Emperor's ``clothes'' were that weren't really there.

>>1
* proprietary
* bloated
* overcosted
* dubious security and update scheme

Need I say more?

>>44

Back to 4chan, please.

>>45
why did I even bother writing walls of text when you just reply with your usual bullshit? I guess it's my fault because I tried to explain things to you and have a reasonable discussion. while C can be blamed for some security issues, your idea that security wouldn't be a problem without C has as much to with reality as the idea that if C was not invented we'd have flying cars, cold fusion and anime would become real. you spend your time shitposting about mental midgets but the real mental midget was you all along.

>>49
You think programming should suck forever because someone can call and say ``I'm with the FBI and I need your password to fight terrorism'' and some people might fall for that. That is ``mental midget'' thinking and that's why Satan wins. I don't believe that we shouldn't focus on things we can fix because of things we can't fix. Maybe if a less bug-prone language was used and we didn't have to spend billions of dollars fixing buffer overflows, we would have flying cars. Nobody would ever know what that money would have been used for.

>>50
what are you babbling about? I never said any of that, I only said that (from experience) many security issues are not related to the use of C language you dumb fucking idiot. stop projecting and strawmanning or just go fuck yourself.


I know, IHBT

>>51

many security issues are not related to the use of C language

That's true, but many security issues are and that's exactly what my response >>50 is about. Programmers convince themselves that C is good but they're too stupid or incompetent to see why and they blame themselves for bugs that would not happen in any other language, exactly like they are convinced that the Emperor is wearing these really fine clothes they are too stupid or incompetent to see.

There are some bugs that will not be solved by any programming language, like people pretending to be FBI agents, but if we get rid of the problems that were already solved decades ago, we will have more time and money to solve real problems that are not so easily solved.

Satan is

Stopped reading there.

satan=systemd

>>54
This.

>>54
systemd is written in C and managed with the ``information manager from hell''

>>56

systemd is written in C...()

So is OpenRC, except the latter wasn't written by an incompetent shithead.