Has security holes out the ass

>But sometimes you have to do lower level stuff.
C++ serves every single low level need C could possibly offer you and does it better.

I rarely even use single inheritance lmao

Can we stop C++? At this point it's like the Frankenstein's monster on steroid.

>No RAII
This is a bad thing.
>High performance
Lol no. C++ has better potential for performance at less of a cost. Ctards write shit inefficient code all the time because the faster alternative is too inconvenient to write.
If you want performance, C++ is the language to use, not C.
C is for when you want to be part of a cult.
>It's not C++
This is a bad thing.

No, it really doesn't. Please stop saying this. Don't get me wrong, I prefer C++ over C for userspace any day, but it simply isn't a feasible option when you need to do stuff in kernel space. Not to mention that for a bunch of hardware/architecture stuff, you'd end up writing non-idiomatic C++ anyway.

RAII/Destructors are ok if it's optional. How you keep a destructor from being called in C++?
> C++ makes it more convenient to write fast code.
Um like what? C++ makes it more convenient to write slow code though through non-zero cost abstraction.

>Language has security holes, not the garbage I wrote in it

Attached: serveimage(38).jpg (645x729, 57K)

Yes it does. If you believe otherwise you simply don't even know C++.
C++ may not be a superset, but it supports like 99% of things in C, you can easily write C like code and mix in C++ features to make things more convenient for yourself.
Even the fuchsia people caved in and used C++ for their virtual memory manager.

>How you keep a destructor from being called in C++?
Don't write one.
If you have a destructor and don't want it called, you're doing things wrong.

The standard C library is filled with holes like proper bounds checking and it's code that hasn't been modified since the 70s or whatever decade back then. You can do integer overflows and integer underflow and such.

So you can't? Hoped there was a secret way to do, like how I never knew about placement-new in C++. :/
If I don't need to call destructor because I'm dealing with a copy, then RAII is just annoying.

You clearly don't understand what I'm talking about, just fuck off.

I'm not saying C++ is bad, I'm actually saying that it is good. But try writing a Linux kernel module in C++ and make it load, you'll not only lack all features that makes C++ worth using (such as STL and exceptions and vtables), but you'll spend six months trying to hack the Linux build system into compiling your module in the first place. Only someone severely autistic would find this to be an acceptable alternative to just getting your hands dirty and doing it in C to begin with.

Please stop spouting the meme that C++ can simply replace C on day one.

>If I don't need to call destructor because I'm dealing with a copy
Pass a reference, you dumb retard. No destructor called.

Simply means you are supposed to do the bounds checking yourself ;-). And I agree there could be improvements btw... If we are going to complain about standard libraries, why is there no realloc in C++-allocators? That's inefficient!

gets()

Not the guy and I agree with what you're saying, but that's more of a fault of Linus for writing the kernel in C than it is an inherent advantage of C over C++.

man gets
>NEVERUSETHISFUNCTION
wow that was hard

Preventing destructors from being called is dumb. Placement new actually has a legitimate use. Preventing destructors from being called is something only a C programmer inexperienced in C++ would want.
Giving your type a destructor tells the compiler you want this destructor to be always called at the end of scope.
If you didn't want that, then make it a method/function that you have to call manually.
>If I don't need to call destructor because I'm dealing with a copy
You still need to call the destructor to free the copies resources. Why wouldn't you?

>all features that makes C++ worth using (such as STL and exceptions and vtables)
>exceptions
Bait.
>and vtables
Except you can use them. vtables require no runtime library support.
The STL is not the only thing that makes C++ worth using, it's the language features also that make C++ worth using even in embedded.
And I don't know why you're bringing up existing C projects. You need to use X project's language to work on X project, no fucking shit nigger.

Of course it is. My argument is simply that sometimes the course of least resistance, i.e. writing C for kernel space or maintaining a legacy project, is a valid reason for using C. The infamous cat-v/Linus rant on C++ that gets posted here from time to time clearly demonstrates that Linus' view on C++ is extremely dated and full of weird preconceptions.

>Not a compiler error
It's shit.

>Bait.
It's not. Exceptions are an inherently better approach to error handling than passing return codes, especially when combined with RAII.

>Except you can use them. vtables require no runtime library support.
The point of using C++ is that you have a high-level language support that implements this. If you're going to manually implement vtables, you're essentially programming C (and exponentially increasing your odds for doing something wrong or insecure).

>The STL is not the only thing that makes C++ worth using,
I'd say it alone is 90% of the reason why I prefer it over C. Not having to implement maps and array lists every fucking time.

>it's the language features also that make C++ worth using even in embedded.
Hey, I said nothing against using C++ in embedded environment. In fact, I prefer this. Note that I explicitly mentioned kernel hacking.

>And I don't know why you're bringing up existing C projects.
Because that's literally what I said in my second post, you disingenuous little fucker.

>Hoped there was a secret way to do
Alright, I'll show you how it's done, but it's completely fucking retarded and you should never, ever do this under any circumstance ever in proper C++ code, and if you do then fuck you, seriously. You're a goddamn fucking idiot who shouldn't be using C++.
void stupid() {
alignas(Foo) char _foo[sizeof(Foo)];
new (_foo) Foo();
auto &foo = *reinterpret_cast(_foo);

foo.some_method();

// foo.~Foo never called.
}

Your logic makes you sound like an idiot. An enormous idiot.

Stop, you're replying to bait. The proper way of "dealing with a copy" is to pass a reference.

>has security holes out the ass
name one security hole in the C programming language that is not attributable to bad programming
i'll wait until this thread dies

Attached: 1547008743050.png (667x720, 387K)

>Exceptions are an inherently better approach to error handling than passing return codes
As of now? Definitely not. Any overheadful abstraction is not worth using. Wait until the zero overhead deterministic exceptions proposal passes and then I might agree with you.
Maybe types are definitely better.
>The point of using C++ is that you have a high-level language support that implements this. If you're going to manually implement vtables
>If you're going to manually implement vtables
You don't understand.
You don't need to implement anything yourself. They just work normally without any runtime library support. The compiler outputs the vtables itself without any need for runtime support. You don't need to do anything, you can just use virtual methods like normal and they just work. You never need to implement any vtables yourself.

>The proper way of "dealing with a copy" is to pass a reference.
That's not a copy you dumbass.

never heard of it.
is it some kind of ultra-autistic hipster meme that won't survive until 2020?
pic unrelated

Attached: c61.png (800x750, 106K)

Undefined behavior

>As of now?
Yes, as of now. It's infinitely better than returning error codes. Returning error codes and manually releasing resources didn't even make sense in the 70s, which is why Dijkstra advocated exceptions.

>Maybe types are definitely better.
Not arguing about this, although I think they have different purposes. Exceptions are for unrecoverable errors, where you should release all resources. Maybes are for when you can deal with it locally. Note that I explicitly compared it to returning error codes, not to other mechanisms.

>You don't understand.
>You don't need to implement anything yourself.
>They just work normally without any runtime library support.
Fair enough, I was a bit quick on the trigger there without thinking through. You have a point. You still need to deal with the compilers namespace mangling if you plan on linking in the kernel, but yes, you're correct that you don't need to look up in vtables yourself and that this is compiler generated code.

Define a copy then.
If you acquire resources, they should be released.
If you don't need to acquire resources, then you should only reference them.

and when does this happen?

Attached: 1544167397003.jpg (384x384, 29K)

When and only when your language has explicit support for it

Teach me to hack in kernel space

tldp.org/LDP/lkmpg/2.6/html/x121.html

>a language has security holes
opinion discarded.

every case of undefined behavior is still attributable to inferior programming practice

>C is great because you can do anything with it!
>No wait, you can't do that!!! That's not allowed!

But it's no excuse for an inferior toolset

As someone who writes 6502 machine code, I don't get why you yonguns bitch about C.
It's on the metal. It acts like something on the metal does, and makes assumptions for you, because if you wanted to be any more specific you'd also be writing machine code.
Then people who'd rather be fucking miles above the metal either mistakenly write C not understanding what they're fucking doing, or see others happily writing C and bitch about them for playing with 110v AC wires rather than 5V DC electronics, and get scared.

>a car is great because you can drive anywhere with it
>no wait your not allowed to drive on the wrong side of the highway
but you're still the retard for misusing the tool

Attached: 1550247376975.png (1875x1779, 2.6M)

>It's on the metal.
The point is that it's not. It's a high level language. Any hardware architecture specific code is by C's own admission either undefined, unspecified or implementation defined.

>and makes assumptions for you,
If it makes assumption for me, it is by definition not "something on the metal".

>because if you wanted to be any more specific you'd also be writing machine code.
Exactly, that's why C should stop being retarded. A language that specifies undefined behaviour like it was a datasheet for hardware is just fucking absurd.

The original sin of C++ is using other people's code. The virtue of C is being able to start from scratch with only a compiler (which you wrote) and develop a full stack on the bare metal that runs the entire machine. When every line of code on a computer is written by you, the responsibility and power to make it safe and secure all rests on your shoulders. Rising to meet that responsibility is what separates the weak from the mighty.

Don't be a "programmer." Be a god.

C# does multiples inheritance tho

Driving on the wrong side of the highway is a rule prohibited by society, in other words it would be similar to a programming convention (such as caller being responsible for freeing). The equivalent of a car would be that if you drive it offroad, demons would fly out your nose. That's how ridiculous undefined behaviour is.

no it isnt
in either case it is you who is at fault

>no it isnt
Great argument there buddy.

>in either case it is you who is at fault
Doesn't make C a good programming language or any less absurd.

pretty sure it doesn't one base class that's it. you can implement multiple interfaces though and you can have class hierarchies larger than one layer but no multiple inheritance like c++ allows. also I post that image ironically I have no horse in this race just a hater of rust.

Driving on the wrong side of the highway is a good analogy. You only encounter undefined behavior if you deliberately do something that's obviously wrong. The people afraid of UB are the people who don't know a damn thing about C.

C is nowhere close to modern 'metal'. It doesn't see branch prediction or CPU caches. It sees the abstract virtual machine built to run C code that runs on top of the actual hardware.
In the mean time go see how the machine code for Symbolics machines looked. Hardware being hardware doesn't imply it needs to be 1970's PDP 11 kinds of primitive.

You cannot misuse something you don't use.
If misuse makes you a retard, not using things is a good way to avoid it.
Therefore, smart people don't use tools that can be misused.

It also means that undefined behavior should be illegal and punishable and C should have something along the lines of road fences to stop it from happening...

Driving on the wrong side of the highway will work fine when there is no traffic or police.

Writing code with undefined behaviour can literally make even your compiler crash or it may open emacs and run a tower of hanoii simulation.

Don't be stupid. Driving on the wrong side of the road isn't illegal. The only punishment is your own death.

>Driving on the wrong side of the road isn't illegal.
Driving on the wrong side of the highway is very much illegal and will land you a hefty fine/prisontime + automatic suspension of your driving privileges.

Meanwhile, programming in C doesn't require a license like driving does.

There's no law like that in any country that matters.

>A handful of central african countries are the only country that matters

Are you the only person to use your software written in C?
Do you use any software written in C by other people?
Would you honestly take a bunch of innocent people on you when driving on the wrong side of the road, or would you honestly take a ride offered by someone who does?

>he cares about security holes on air gapped embedded systems.

of course not you expect the driver to drive safely from point a to point b as you do in regular traffic
and the expectation on anyone writing software professionally is that they know what they are doing
you wouldnt want to fly in a plane with someone who boasts about how much of the flying the autopilot actually does for them and hoiw they barely touch the controls or even know how to fly without autopilot

Ideally, all computer users would have to write their own software just to be able to boot up.
C is the key to this dream.

>It's infinitely better than returning error codes
Of course it is but maybe types are better than both.

>If you acquire resources, they should be released.
Exactly.
>Define a copy then.
Any copy-constructor initialize object.
>If you don't need to acquire resources, then you should only reference them.
Exactly.

While the C++ virgin is being pissed on by his language, the Rust chad gets things done.
doc.rust-lang.org/std/mem/fn.forget.html

Nonsense, there's no Rust code that compiles, let alone actually runs.

You can do this in C++ too. Just move out of the object.

what is this rust?

Proof that Rust is dead: Someone on Jow Forums, the only place in the world where it gets shilled, has never heard of it.

I like having few powerful rules and granular accuracy.

Entire computing paradigm can be built on two of the sixteen possible boolean functions.
Germinate on that.

Attached: god i wish that were me.jpg (1000x1360, 133K)

There's a major distortion in the judgement of the language here.

C
>runs on damn near everything
>offers the best performance
>by virtue of running on everything and being relatively low level, controls and protects innumerable amounts of data and property
Because of this, not only is there a huge motivation to look for holes to steal/wreak havoc, there's also a push to publish those holes, to protect and warn.

The question isn't whether there's security issues with C, the question is, is there another language that can do all C can do AND be more secure.
And the answer to that is, we don't know, because no other language has ever been the de facto low level language of the world, ever.

You can recite your alternatives, but no other language has ever ran on such a wide array of processing elements, protecting so many lives, so much property and data, as C had.

Attached: 1444359025409.png (476x530, 204K)

>People itt conflating language and implementation
Read your compiler docs, kids

This instantly debunks any claims about safety in any language. All languages have UB, all of them have memory corruption, it's just a matter of time and popularity before the ways to do it are found and documented. They're starting to find these in JS, you can change arbitrary memory.

i was just baiting the tard, but you're right, this really is the only place i've heard about it. i don't know where do these brainlets find all the meme languages

If you're programming embedded, C is the way to go. It's a beautiful language and it's fairly intutive. It's also the perfect language to improve your skills as a novice, since it won't leave you with any gaps in your knowledge. Some people think they're programmers because they work in JS or Python. These people are scripters or webdevs, not computer programmers. Computer programming means programming a computer, how the hardware functions and what low level tasks it performs. Personally, I think using C for anything other than true embdedded is boring. C++ and Rust are great languages too, but C is extremely lean and still contains everything you need in order to do anything. If you ride a motorcycle and crash it, it's not because "motorcycles don't work", it's because you made an error.

get out from under your rock retard.

imagine shilling a doa meme and failing this badly, no shekel deposited in your account

Attached: c0c.jpg (634x650, 45K)

Wrong. C++ is not smart enough to know if an object has been moved from, and will still run the destructors.

So? It won't destruct the resources.

java cant multiple inheritance but c++ cant into circular dependency

C++ can do circular dependencies with header files.

Can I write a kernel from scratch in Rust, though?

no, by the time you finish writing it rust will no longer exist

This, it's like a black hole. Nothing comes out of it and sooner or later it evaporates.

>waaa i write shitty code that has security flaws FUCK C WAAAAAA im given too much freedom WAAAA i want training wheels please mommy give me training wheels

Attached: CFD494CD-6CBB-4175-89D6-D9E81A510EE2.png (548x502, 335K)

NANI

The C Programming Language

Attached: TheCProgrammingLanguage.png (1200x1686, 87K)

Because AT&T and Bell Labs ran an incredibly successful revisionist campaign, to the point where people believe C was the first high level language after assembly.
We had better machines, operating system and languages in the '60s and '70s, long before Unix was created.

C objectively has glaring security issues regardless of whether people look for them or not.
Brain damage such as null terminated strings and array decay shouldn't even exist in the first place.

>believing c programmers can do that
yodaiken.com/2018/06/07/torvalds-on-aliasing/
Daily reminder it's impossible to use C correctly, even Linus doesn't understand the standard and advocates for ignoring it, basically inviting UBs and subtle bugs:
> Don't tell me "the C standard is unclear". The C standard is _clearly_ bogus shit (see above on strict aliasing rules), and when it is bogus garbage, it needs to be explicitly ignored
> The standard simply is not *important*, when it is in direct conflict with reality and reliable code generation.
> I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality. It has absolutely _zero_ relevance. In fact, I'll take real toilet paper over standards any day, because at least that way I won't have splinters and ink up my arse.
No, you can either support him, basically turning gcc with a set of the compiler options into the de-facto C standard, but then it's no better than other languages without a standard and you're a hostage of the horribly maintained project gcc is. Or you can argue against him, but then you have to somehow show that competent C programmers even exist, because the most famous C programmer in the world is clearly incompetent.

>claiming a fucking programming language where it is YOUR FUCKING RESPONSIBILITY to build the goddamn program up and make it secure and usable has "security holes"
I've said it a billion times, I'll say it again: If you think C sucks, you're a shit programmer.

I know this is bait but I'll bite:

People who think this shit in real life are insufferable faggots who have 0 concept of how much abstraction there already is between them programming in "real" languages bare metal. The amount of abstraction that's achieved by going from logic gates to C is fucking astronomical, and you could probably never achieve writing a C compiler from bare metal in your entire life if it weren't for the work of hundreds of years of mathematicians working all this shit out for you. Comparatively, the jump from C to Python is minuscule in the grand scheme of things. Sure it might abstract away a few data structures and make things nicer to use, but it's nothing compared to carefully organizing bits of sand together in such a way that they perform actual computation.

Computer science and abstraction are tied together at the hip. Losers who can't understand that the continuous abstraction of mathematics is the very essence of computing are the most obnoxious fucking faggots in the world. The losers who can't understand that it's actually harder to think abstractly are the funniest of them all. Sure you can do the equivalent of hand-holding a modern abacus. You're not accomplishing anything by reinventing the wheel for the thousandth time, you're just doing it because someone needs some retarded shit to be fast, but you're not furthering the field of computer-science. You're not developing new fucking algorithms in C, you're implementing something that someone (far smarter than you) has already thought of in a slightly different flavor just so you can get a paycheck.