MULTIPLE VULNERABILITIES IN THE RUST PROGRAMMING LANGUAGE

Rust can't compile itself on x86 because it somehow runs out of registers. Meanwhile, Ada works just fine on embedded stuff, vehicles, and planes. If any language here is a LARP language it's definitely Rust.

Attached: 1447094984513-0.png (670x420, 378.23K)

top kek.

Rustfags love to brag that the compiler stops them from acting like a retard, the solution? Don't code like a retard, retard.

Attached: 200% nice.png (371x532, 280.83K)

Holy shit. He's right.

Oh my G*d, so this safer language I vehemently hate because of political reasons has some vulnerabilities. Better shill my shit language with no security because muh SJWs and fee-fees!

Learn to read and watch It answers your questions about memory safety and Rust.

it's inside an unsafe {}. Look for those, found your bug.
Here's all the forests on all the planets in the galaxy: one of the leaves on one of the trees is bad. Hey man, I narrowed it down to a galaxy for you :^) For an example of this, check out modsec 2.x (3.x is a C++ rewrite). Every single memory allocation is explicitly allocated from a memory pool. There are many memory allocations. One of them mishandles the memory pool. Result: Apache later tells libapr to clean up its pools after an exec -> libapr tries to 'clean up' a circular list -> Apache is stuck in an infinite busy loop and uses 100% of CPU.
Pretty shameful display from the Rust people, but they forgot shame when they accepted a dining philosophers example using a bunch of Communists.
The memory pools are an implicit feature of the language in Ada: you can't accidentally break them. Overflow checks + the culture of defining your own types would discourage Rust's math/API error. Rust's unsafe { go fuck yourself } vs. only-provably-safe-code dichotomy encourages memory errors like this: there's no reasonable automatically-checked-cause-not-proven intermediate state.

B-B-But Ada is old! And it was probably developed by people who have alarming views on race, privilege, gender, transpeople and are bigots. Rust==Resistance! (At least that's what I get from their PR)

Attached: ex-rust-developer-interview.webm (896x504, 10.61M)

totally forgot that I had that in my webm folder too.
I also have one for which I posted a fucking yt link

Attached: Theo_de_Raadt_vs_Rust_(EuroBSDcon_2017).webm (1280x720, 8.46M)

This is why bloat and security aren't compatible. You can't have a libstc++ tier stdlib bloat without having bugs. Same reason using Java for security is retarded when OpenJDK makes OpenSSL looks good.

Ada's original chief designer was one of (((them))).

Attached: Photo_jean_ichbiah.jpg (550x770, 38.84K)

If I recall correctly they just turn off all safety shit for performance anyway until it becomes an shittier version of C.

Attached: tad.improving_c_language.webm (316x236, 159.58K)

Stopped listening right there. ls is right here: github.com/uutils/coreutils/tree/master/src/ls
Who fucking cares? POSIX is shit.
Who fucking cares? 32 bit is deprecated.

If Ada is so good, then why aren't we using it for all system programming?

Attached: G1.jpg (362x220, 12.36K)

>ls is right here: github.com/uutils/coreutils/tree/master/src/ls
This is literally CS grad tier code. Compare rust version to github.com/coreutils/coreutils/blob/master/src/ls.c The difference is like night and day. C version reads like classical literature, while Rust version is an essay written by a college kid that just want's to get 50% so that he passes the class.

Attached: Screenshot at 2019-02-03 19-51-41.png (901x869, 165.09K)

epic
if (S_ISREG (mode)) { type = C_FILE; if ((mode & S_ISUID) != 0 && is_colored (C_SETUID)) type = C_SETUID; else if ((mode & S_ISGID) != 0 && is_colored (C_SETGID)) type = C_SETGID; else if (is_colored (C_CAP) && f->has_capability) type = C_CAP; else if ((mode & S_IXUGO) != 0 && is_colored (C_EXEC)) type = C_EXEC; else if ((1 < f->stat.st_nlink) && is_colored (C_MULTIHARDLINK)) type = C_MULTIHARDLINK; } else if (S_ISDIR (mode)) { type = C_DIR; if ((mode & S_ISVTX) && (mode & S_IWOTH) && is_colored (C_STICKY_OTHER_WRITABLE)) type = C_STICKY_OTHER_WRITABLE; else if ((mode & S_IWOTH) != 0 && is_colored (C_OTHER_WRITABLE)) type = C_OTHER_WRITABLE; else if ((mode & S_ISVTX) != 0 && is_colored (C_STICKY)) type = C_STICKY; } else if (S_ISLNK (mode)) type = C_LINK; else if (S_ISFIFO (mode)) type = C_FIFO; else if (S_ISSOCK (mode)) type = C_SOCK; else if (S_ISBLK (mode)) type = C_BLK; else if (S_ISCHR (mode)) type = C_CHR; else if (S_ISDOOR (mode)) type = C_DOOR; else { /* Classify a file of some other type as C_ORPHAN. */ type = C_ORPHAN;}

kys. rust is just shit, why is this surprising? memory safety still remains trivial to solve as done in Lisp and SML. you could literally implement a memory-safe PL yourself in a day and add some interop for networking and framebuffer and it will be better than any existing system

Because "we" (you, not including me) are retards.

spotted the LARPer

Fuck you sage nigger. Eat a bag of dicks.

Ada isn't "C plus runtime checks". Even when you turn checks off, you have a better language.
Ada also performs well with checks on. Enough for non-embedded platforms. If you write an O(N^2) 'Pre' check, you might want to disable that for release.
As a practical matter, you can segments of get high performance Rust code by being really careful in an unsafe {} block. If you can get the same performance by writing Ada completely normally and then removing checks from that segment, this is also going to be the less-error-prone option.

eh. SML's alright, but "segments of high performance Lisp" could have this exact bug.

As a practical matter, you can get segments of high-performance Rust code by not misplacing entire words.

Use F*.
fstar-lang.org/

Sunk cost fallacy: the language

Risitas never gets old

>bugzilla.redhat.com/show_bug.cgi?id=1632932
fucking what

it's CSS doing that.
you don't need JS to read the page though, that's just shitty design.

Rust is just a desperate attempt by Mozilla to stay relevant. You can see how much they realize Firefox is a failure now and they need something else, and they think it'll be Rust, by how strongly it's shilled all over the internet.

Nothing is safe on a computer. You should never assume it is safe.

C takes safety and places it into the programmer's hands. If there's a problem with a program, it's because the programmer fucked up in one instance. Meaning if you want to find an exploit there, you have to comb through the code and find where they fucked up.

Rust embeds those problems into the language itself. Look at this, str repeat has a buffer overflow. Now you can exploit any Rust software that uses str repeat. Rust is like using defective libraries all over. And as other anons pointed out, it's all false security, so those libraries were probably made by a bunch of people going
as we've all seen by the bullshit shilling that happens here and all over the internet.

Rust is an attempt to take the scary part of programming away from users, like Visual Basic, Javascript, etc. And it has the same exact problems as those languages. They are restrictive. And when there's a problem with the language or build in libraries, it spreads everywhere.

Interesting. How performant is it?

And you think C is better in this aspect? libc implementations have had security issues too.

Attached: 1549137264643.png (917x2017, 728.25K)

Autistic technology oriented Jews are the best Jews.

We are. It's just that you're not one of us.

Rust and Go are both memes, you can tell by the amount of shills their sponsors need to hired to try to force them on the public.

Rust really is shit.

The whole point of Rust is to make Mozilla bloatware like libxul (around 100 MB stripped) more maintainable.
You could say the same thing about UNIX, Linux, and Plan 9 code. UNIX bc is so full of bugs that numbers get corrupted. They managed to make a "calculator" that can't do math.
Do Rust compilers delete null pointer checks and change the meaning of code it assumes to be "unreachable" because of "time travel" bullshit that has no relation to any physically possible or hypothetical machine? C compilers do.

Assembly is safer than C or Rust because you have full control over the instructions, but people realized early on that it's usually better to have programs that write programs (aka compilers) because the author of that program can do it once instead of having to write the same code over and over again. One of the things that sucks about C is that it forces you to keep writing the kind of tedious code that computers are good at handling.
Those "standards" are mostly workarounds for C brain damage.
wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152364
Simple link-time type checking solved this problem decades ago. UNIX is stuck with a linker designed for PDP-11 assembly.

It's mostly smart people who know C inside and out who hate C. C weenies think they know C but actually don't, which is why they can't understand all the bullshit in the standard. They learned what someone else thinks C is from books instead of learning the real language.

Ada without runtime checks is still a better language than C. Ada has pragma Restrictions as a standard feature to disable specific features of the language. The No_Exceptions restriction is a standard feature of Ada.

Weenies don't want to use Ada because it solves too many problems, like that article on hacking a computer via DNA.

Bullshit. Assembly language "takes safety and places it into the programmer's hands" because every instruction is written by the programmer or by a macro the programmer chooses to use. C puts safety into the hands of the developers of the compiler and libraries. C compilers do all sorts of complicated bullshit to your code, which is necessary for the "speed" C weenies brag about. C is not assembly and has nothing to do with how hardware works (besides RISCs leaving out features C doesn't need and making everything else slower).

Every bug in any level of software, including compilers, is because some programmer fucked up somewhere. UNIX needs more than 60 million lines of code just to approach the usability of a Lisp machine, and UNIX is still worse. Lisp operating systems like Mezzano reduce the distinction between macros and the built-in parts of the compiler. The whole thing is a modular Lisp system where many of the optimizations (compiler macros) are kept with the modules themselves instead of baked into the compiler.
github.com/froggey/Mezzano/search?q=define-compiler-macro

Of -course- mail to Unix-Haters fails to blame anyparticular responsible individual. -Every- little bug orproblem is actually the responsibility of some individual,if you could only figure out who. The problem is thatdealing with Unix seems like a grand game of finger pointingand pass-the-buck (without Harry Truman). Is the realproblem that the programmer didn't check the array bounds?Or is it ultimately the fault of the designers of C fordesigning a language in which programmers must error checkarray indices manually?Eventually, you stop caring about the details that would letyou sort out who was responsible. Recently I was unable touse FTP on a PC to send a file to my directory on a Unixmachine because on the Unix box I use the `bash' shell.Heaven help me, I even understand why this restrictionplugged yet another security hole in Unix, and I was able toremove the restriction as soon as I understood what washappening, but after enough absurdities like that, youraverage user has no energy left to assign blame. What doall these bad experiences have in common? Unix! Thus, Unixis the problem.

based

Now remind me how your precious Lisp needing a fuckhuge garbage collector to be performant isn't a problem.
Nice joke.
Probably slow as fuck.
Joke of the century, nice of you to link it.

Known as "how to make lambda calculus look ugly". Use Scheme for syntax purity or SML/sML for an actually usable language; dynamic typing is just a retarded shortcut to avoid the task of designing a type system while pretending that the grape is sour anyway.

also based

I agree that many RISC implementations are a little too barebones, but stuff like x86 and x86_64 are far too fat. They're so fat that the sheer number of instructions is becoming a bottleneck and CPU designers have moved to emulating it on top of specialized RISC processors to get anything resembling good performance.
If you're interested in processors doing useful things, take a look at RISC-V's Standard Extension for Vector Operations. It takes some cues from the Cray in hopes of avoiding other ISAs' neverending vector extensions.
Most of those 60 million lines are drivers. Cut out the drivers you aren't using and even on a fat kernel like Linux there's a very impressive reduction in size.

Attached: 1447959341525.png (346x334, 239.67K)

Firstly, in what universe has a Lisp machine ever come close to modern *nix in usability?
Secondly, as said, much of the codebase is drivers. You kinda need those if you want hardware compatibility.

What's the point of rust again? Is it a containment language for all the freaks and trannies and homos?

That doesn't even resemble what's actually going on.
The bottleneck on your modern amd64 chip is two-fold.
1. since it's an OOO machine, with a ROB that tracks dependencies and executes instructions in dependency order, it's IPC limited by the amount of dependencies and how granular said ROB can be made. 8086 and 80386 compatibility comes with an absolutely immense amount of global state and extremely strong ordering. At some (very early) point it stops making sense to just increase the size of the register file. The dirty secret of OOO execution is how very in-order it really is.
2. instruction decoding is obscenely complex, so every instruction decoder ends up being a deep variable length pipeline of nightmares. The most common instructions have to be decoded in fewer stages than less common ones, but you also need to take into account what you can issue more of concurrently. It's a mess, and it's once again because it has to be compatible with half a century of development by accretion. You stand no chance of reusing instruction decoders across reworks of anything, because it's all so intensely interdependent that everything ends up being a ground-up rewrite.
Add to that that most advancements in single-core performance is still down to changing restrictions of fab processes...
What you (wrongly) call an internal RISC machine is nothing of the sort. It's extremely CISC on the inside as well. Just because it kinda-sorta re-encodes instruction to a wide set of internal signals doesn't mean it in any way resembles anything you could conceivably call RISC. The way they actually become fast is by being about as non-RISC and doing as much speculative execution as possible.
In fact, conventional VLIW processors resemble RISC much more internally that amd64 machines do, and they still look nothing like a RISC machine and more like DSPs.
The actual amount of instructions is in no way a problem. Just look at other VLIW machines. They will usually have humongous list of instructions. Some of them very CISC and difficult to execute. The difference is that they're properly structured to require as little decoding as possible so you can issue 10s of them in a single cycle.

He's probably focused on the AMD K5 for this internal RISC thing. Don't know if it's still correct for modern CPUs, though.

Everything that hates unix and loves rust sucks nigger dick on a regular basis.

finally, someone who has at least some understanding of the matter at hand

What a shitty language.

It's not live action, stop perpetuating this shit meme. Just say RPing or roleplaying.

It is live action.
merriam-webster.com/dictionary/live
merriam-webster.com/dictionary/action

It's live action because this RP isn't happening in story form but rather by actions in real life.

you're wrong
anti saged btw

cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html
OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

Attached: 7a4b230d24ae4092d9e74d3b909fa20a6220a705437018869a9bdd047e7f3aee.jpg (248x189, 17.05K)

Stay mad 0.36%. Nobody cares about you.

I'm not mad at all. My thread was up long enough. It served its purpose.
He says while (You)ing me. Thx

sudo apt-get remove rust* libstd-rust* cargo*

sudo apt-get remove snapd* libsnapd*

I use Arch GNU/Linux

Don't forget to sudo ln -s /bin/rm /usr/bin/rust

cvedetails.com/vulnerability-list/vendor_id-23/product_id-17236/Debian-APT.html

cvedetails.com/vulnerability-list/vendor_id-15714/product_id-32625/Sudo-Project-Sudo.html

OH NoNOnoNONo.... OHOHH NOOOONOONONO.... BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

Someone forked my repo

wrong thread srz

medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6
 > The current policy is that we only support the latest Rust
 > The general feeling is “if it’s important enough for a point release, it’s important enough for a CVE”
 > This specific patch does seem like it should have gotten more attention at the time
 > This stuff also obviously ties into LTS stuff as well

Attached: Screenshot at 2019-02-06 12-55-56.png (713x400 55.45 KB, 36.79K)

What's your argument here? I'm struggling to see even a semblance of one.

Attached: not an argument.jpg (500x534, 39.03K)

...

BAZINGA
No seriously. You just quoted a few sentences from an article about a bug in Rust's VecDeque implementation.
What is your point?

There was a buffer overflow bug in the standard library’s implementation of a double-ended queue, but rust developers didn't file a CVE. It was added only after writer submitted it himself, so basically people were running vulnerable versions of Rust without knowing about it.
Well people don't update often and that version was still in debian's repos. It makes me wonder how many more unreported security issues are there?

So what has this to do with ? You posted some CVEs from two random programs as an argument against removing Rust.
rustsec.org/advisories/
BAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAAHA

Everything written in C/C++ is vulnerable by default. What is your point?
If you don't update you won't get fixes.
C/C++
no. I replied to two shitposts with my own shitpost.

To which I replied with yet another shitpost. This whole thread is just shitposting.

int main(void){ return 0;}
Where is the vulnerability?

agreed

In the compiler
cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html
cvedetails.com/vulnerability-list/vendor_id-13260/product_id-27514/Llvm-Clang.html

Peak LARPing.

REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
THIS ISN'T LIVE ACTION
you're right though

Oh I find them and remove them too.

What the fuck?

CVEs are funny

Look at this dood.

...

Crazy C compiler optimizers are indeed fucked up and I constantly criticize the compilers for that. However that's an issue of implementation, not language.

I do hate C but I hate every other language even more. What I hate most though is how every single language imports the entire C world into it. Because of this I've been working on freestanding programs that talk directly to Linux instead of using libraries.

I absolutely hate the C standard library. Freestanding C is a much better language just because there's no standard library in it. What I like most about C is how it generates the code I want. It compiles down to the assembly I expect, especially when using -Os.

My long term goal is to make my own programming language with no dependencies and no external libraries, not even libc. And then write everything in it.

Me too, but that's because I enjoy working as close to the machine as possible. I have no fute against neo-programmer types and their love for abstractions, but I must admit I don't understand the fun in it. I do as I've done since DOS and I like it. Never had a "I hate programming"-day.

Attached: computer_home_decoration.jpg (1894x1636, 355.94K)

Well I started liking programming a lot more after I dumped the library bullshit.

Forth.
Zig although the compiler has dependencies the size of a planet.
But just use Ada.

Rust is yet another example of a thing that could have been good, except they decided they knew everything and thus had no need to consult the literature.

you mean separation algebra

you mean separation algebra

which is all the time so what's the point

Maybe instead of wasting a fortune reinventing square-shaped wheels Mozilla should read a book every now and again and consider putting their weight behind a *good* idea, even if *gasp* it wasn't invented at Mozilla.

vst.cs.princeton.edu/ write C, prove its correct, move on with life stop trying to reinvent everything

Attached: VST-diagram.jpg (1013x1071, 279.83K)

vst.cs.princeton.edu/download/VC.pdf
unsigned sumarray(unsigned a[], int n) { int i; unsigned s; i=0; s=0; while (i

fucking LOL

how about
for (i = 0, s = 0; i < n; ++i) { s += a[i];}instead?

how about
array.iter().sum()
instead?
play.rust-lang.org/?gist=7c2ea621441055ba3cc473bcba196e21

Both while and for are synctactic sugar and social constructs, if and goto oughtta be enough for anybody.
i = 0;s = 0;hurrdurr:if (i < n) { s += a[i]; ++i;}goto hurrdurr;

Attached: a19.png (500x375, 251.45K)

goto statement should be still inside the if clause obviously, otherwise it's just going to loop forever