Stagefright or C/C++fright?

There is a technique called stagefright that can exploit a system by playing a video, but this is not an MPEG problem or any other video format problem. It's a C and C++ problem. Malformed data causes a C or C++ program to behave unexpectedly. The C and C++ languages not only cripple your mind, your operating system, and your hardware, they allow invaders to take over your machine by doing simple things like watching a video or generating thumbnails.

There is a technique called stagefright that can exploit a system by playing a video, but this is not an MPEG problem or any other video format problem. It's a human problem. Malformed data causes a human to behave unexpectedly. Humans not only cripple your mind, your operating system, and your hardware, they allow invaders to take over your machine by doing simple things like watching a video or generating thumbnails.

for more information, search more about "tunnel vision and programmers".

>>2
It's not a human problem. C was made by subhumans.

The only solution is Rust. Rust is the only safe programming language that was designed with safety as core part of the language. Therefore, you must use Rust if you want to write software that is not vulnerable to this bug.

I would be interested in rust if not for the excessive shilling

>>6
all the hottest maymay languages get that for a bit and then die off.

Unfortunately compilers convert the C program to an ASM or binary program depending on compiler options. If they implemented the exact library exactly the same with a different compiled language they would almost certainly result in the same exploit. If your solution for this problem is to write your software as an interpreted or just-in-time byte code program on a virtual machine you will now have two problems.

>The underlying attack vector exploits certain integer overflow vulnerabilities in the Android core component called "Stagefright",[6][7][a] which is a complex software library implemented primarily in C++ as part of the Android Open Source Project (AOSP) and used as a backend engine for playing various multimedia formats such as MP4 files.
>this is the reason we need rust
https://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/

"in release mode, overflow is not checked and is specified to wrap as two’s complement."
Of course the inherent safety of Rust can be turned on and...
https://users.rust-lang.org/t/disabling-arithmetic-overflow-checking/546
One test cases for the CPU is to overflow a register and make sure it sets the appropriate CPU flags. When I run this case, the program panics and I get the error: panicked at 'arithmetic operation overflowed' (rest of question is how to turn it off)

>>9
Integer overflow is a detail of implementation and certainly has no basis in the linguistic expressiveness of any given language.

Rather than language you mean to refer to something else. Perhaps a software library, technique, compiler, even computing architecture. If people are unable to separate these things from the language then their arguments become reminiscent of religious rants. Most likely they don't realize that programs written in any language is open to many of the same vulnerabilities given the same circumstances.

Of course the resulting program is parsed and generated based on numerous things. A program generated with one compiler might be very different to a program generated with another compiler, while they do both have the same exact source code.

You would think most people understand these sorts of things even before college.

>Integer overflow is a detail of implementation
Show me another Rust implementation.

>>11
You seem overly preoccupied with incidental engineering circumstances. Considering that both languages are effectively Turing Complete please demonstrate how one TM is necessarily vulnerable where another TM is not. This is completely rhetorical of course because the answer is obvious.

You are complaining about the shitty software engineering of a library on Android devices while applying your criticism to a device agnostic language.

If your attack is on the language itself the question that should be asked must be different to the one you posed. The question must be whether it is possible to make an implementation for RUST that exposes similar vulnerabilities. If RUST is Turing Complete then the answer will almost certainly always be yes.

We can make many legitimate criticisms of the C programming language and it's derivatives but such mundane engineering problems like this one don't deserve any academic debate. It is the purview of code monkeys working for a paycheck and has nothing to do with language or structure.

>>12
As long as there aren't independent implementations, the distinction between a language and its implementation is sophistry.

>>10
No, integer overflow does depend on the language. Ada compilers that do not check integer overflow are not conforming. C compilers are allowed to delete code that has integer overflows.

>>14
So Rust doesn't conform to Rust standard?

>>13
Of course it isn't. The distinction is that the language can exist on paper or any other medium and the operations can likewise be executed on paper. If someone doesn't understand this very simple distinction then perhaps they really have no idea what they are actually doing when they write a program.

If you wish for a language to become broadly adopted then it will most certainly have many implementation in order to function on different computing architectures.
>>14
This is untrue and makes some useless assumptions. Whether a technical standard requires a compiler to behave a certain way is simply specification stipulation that affects implementation conformity nothing more. These sorts of arguments are reminiscent to the arguments that people have given for their preference of Python. They will say things such as "I can do a whole bunch of shit in just one line of code with one function call" and "there are so many easily found libraries that do all the things I want."

Those are some pretty dumb arguments of course. There is nothing that limits a C program or a C library from implementing those things or the things discussed in this thread. There is nothing about a programming language that will somehow extend the capabilities of a computer any more than a program written on paper will create extra pages in your notebook.

Emulating existing syntactical paradigms and primarily attacking vulnerabilities in very specific libraries on very specific implementation for specific machines wont get a fad language anywhere. With some luck continuing down that path will make RUST the next Ruby. Then business executive can spend thousands of dollars learning some new buzzwords together in a classroom with champagne and appetizers. A glorious future no doubt, moving on ...

>>16

If you wish for a language to become broadly adopted then it will most certainly have many implementation

Wishful-thinking-oriented programming

>>16

Those are some pretty dumb arguments of course. There is nothing that limits a C program or a C library from implementing those things or the things discussed in this thread. There is nothing about a programming language that will somehow extend the capabilities of a computer any more than a program written on paper will create extra pages in your notebook.

Programming languages can't do anything your computer can't, but they can prevent you from using the capabilities of a computer, and they can prevent you from building new hardware that has additional capabilities.

>>18
This is untrue. A programming language is unrelated to the physical machinery and the program that compiles the language in to binary or some other form interpreted by another program. Even if a C compiler is used to create a compiler for some arbitrary pet project language which then uses it's own compiler to compile programs in the new language. You're not gaining anything unless the new language is either far more expressive or you can convince a lot of people to create very useful and appealing software for your own turd language. The operations of the machine do not change because of the pixels you view on your screen that make up the letters and symbols.

You could make the same unreasonably ignorant argument with Turing Machines. Since they don't account for limits and constraints that permeate the physical world they necessarily are unable to guarantee any kind of memory or overflow safety. Of course then you would be missing the whole entire point as you arbitrarily place significance on current electric machines with silicone chips.

It's an arbitrary and pointless debate.

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
/thread

>>19
It's only arbitrary and pointless because you changed the topic to an arbitrary and pointless tangent about Turing machines. Holy fuck, this pseudointellectual blather of yours is legitimately making me angry.

>>21
I did not change the subject. The language is a conceptual thing where instead of understanding this you are assuming that the language is contemporary implementations and physical constraints. I am simply pointing out through analogy how utterly incomprehensibly stupid and ignorant your point of view is.

If you don't actually understand what it is you are doing when you write a program then perhaps you have no business in telling other people how they should write programs. Since you seems incapable of differentiating between theory and engineered implementations.

>>22
This thread was never about the conceptual difference between language and implementation until you made it about it, officially because ``Integer overflow is a detail of implementation'' and we are all unsophisticated for not realizing that, and don't you know Turing machines wordswordswords. After all, why care to notice that fixed-width integers inherently have to deal with overflow (being fixed-width after all) when you can just stroke your dick over the course of a thousand words about one pointless tangent after the other, to then gleefully declare everyone stupid again for engaging in a pointless ``discussion''.
It's not even really a discussion, you are just talking incessantly.

>>23
No of course it's not about that and I did not imply it was. The thread is about your genuine lack of understanding the difference between the two things and therefore making false attributions and nonsensical claims of language superiority.

Go and reread the OP where the gist is that certain versions of Android have a shitty library and therefore the languages themselves are flawed. You are simply making a fool out of yourself and I suggest you get acquainted with an introductory course. The MIT 6.001 lectures are still available should you ever wish to progress beyond the level of a coding primate beating your chest any chance you get.

>>24
Never mind, it's terminal. I'm out of this thread.

like cookin H in a plastic spoon

>>25
just be yourself, man