Memory Safety is a Red Herring : rust

[–] SorteKanin@feddit.dk 6 points 10 months ago (2 children)

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)? "Memory safety" is nice since it's concise. Is there another term? Maybe just a "safe" language?

[–] sugar_in_your_tea@sh.itjust.works 12 points 10 months ago (1 children)

Wouldn't that language be called "sound"? A "sound" language would guarantee no errors or surprises in types, memory access, or statement execution. It would need to be qualified though since it didn't guarantee programs are sound (that implies error free), it only guarantees use of the language is sound.

"Safe" language also works, and is probably more understandable by the nontechnical decision makers, though it also needs a qualifier to understand what that means.

"Memory safe" is clear and explains one of the huge areas that it excels at. I would prefer "zero cost memory safety" myself, since that sets it apart from other memory safe languages that have extra costs (e.g. runtime checks). "Zero cost safety" is also fine, though I'd want an asterisk that clarifies what it applies to: memory, typing, and statement execution safety.

[–] SorteKanin@feddit.dk 7 points 10 months ago

Zero cost soundness, I like it haha

[+] lysdexic@programming.dev -7 points 10 months ago* (last edited 10 months ago) (3 children)

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)?

I don't understand this fixation with undefined behavior. Its origins are in the design decision of leaving the door open for implementations to employ whatever optimization techniques they see fit without the specification get in the way. This is hardly a problem.

In practical terms, developers are mindful to not rely on those traits because as far as specifications go they have unpredictable implications, but even so they are never a problem. I mean, even in C and C++ it's trivial to tweak the compiler to flag undefined behavior as warnings/errors.

Sometimes it sounds like detractors just parrot undefined behavior as some kind of gotcha in ways I'm not even sure they fully understand.

What problem do you think that undefined behavior poses?

[–] lolcatnip@reddthat.com 15 points 10 months ago (2 children)

It sounds like you've never had to do real work in a language kind C++ where the compiler is always trying to play gotcha with undefined behavior. You can kind of use tools like AddressSanitizer to catch undefined behavior in testing but you certainly cannot just have a compiler catch it for you like you claim.

[–] bluGill@kbin.social -4 points 10 months ago (1 children)

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

[–] lysdexic@programming.dev 0 points 10 months ago* (last edited 10 months ago)

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.

[+] lysdexic@programming.dev -7 points 10 months ago (1 children)

It sounds like you’ve never had to do real work in a language kind C++ where the compiler is always trying to play gotcha with undefined behavior.

I have over a decade of professional experience working with C++, and it's likely you already used software I worked on.

Throughout those years, the total number of times where undefined behavior posed a problem in any of the projects I worked on was zero.

Please enlighten me about the insurmountable challenges posed by undefined behavior.

[–] lolcatnip@reddthat.com 17 points 10 months ago (1 children)

Dangling pointers, double frees and the like, mostly. Tell me you haven't run into those and I'll laugh in your face and call you a liar.

[–] lysdexic@programming.dev -2 points 10 months ago* (last edited 10 months ago) (1 children)

Dangling pointers, double frees and the like, mostly.

Those are bugs you wrote in. UB is not the problem. Your code is the problem.

Tell me you haven’t run into those and I’ll laugh in your face and call you a liar.

I ran into bugs. Do you understand that UB is not the problem if you're pushing broken code? It's not the C++ standard that's messing up if you're writing in use-after-free bugs.

The irony of your comment is that some implementations take advantage of UB to prevent programs from crashing and actually continue to work in some scenarios such as use-after-free and even dereferencing null pointers. But that's not caused by UB, is it? Those problems are caused by developers like you and me who didn't knew what they were doing and even failed to either pay attention to the errors flagged by compiler and static code analysis tools, or even failed to onboard one.

I mean, think about it for a second. Let's say we have a magic wand that can update any C and C++ standard version of your choosing, and we specify that each and every single instance where behavior is left undefined is updated to specify that the program should automatically crash. Awesome, no more UB. What does this mean for your code? Is it now bug-free? Is it now working well after crashing all the time due to the code you added? What role did UB played in this mess?

Do you understand this?

I repeat: detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

[–] AVincentInSpace@pawb.social 2 points 10 months ago

some implementations take advantage of UB to prevent programs from crashing and allow them to continue after encountering a UAF etc.

Could you provide examples of this?

[–] BehindTheBarrier@programming.dev 12 points 10 months ago* (last edited 10 months ago) (2 children)

I'm just a noob when it comes to low level languages, having only been in C# and python. But I took a course on C++ and encountered something that didn't seem right. And I asked and got the "that's undefined behavior". And that didn't quite sit tight with me. We don't know what will happen? It'll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

Now, it's quite some time since that happened, and I understand why it's undefined. But I still do not think it should be allowed by default. C and C++ both are "free to do as you want" languages, but I don't think a language should let you do something that's undefined especially if you aren't aware you're doing it. Everyone makes mistakes, even stupid ones. If we can make a place where undefined behavior simply won't happen, why not go there? If you need some special tricks, you can always drop the guard where you need it. I guess I'm just reiterating the article here though. But that's the point for me, if something can enforce "defined behavior" by default then I'd want that.

[–] Sylvartas@lemmy.world 2 points 10 months ago (2 children)

We don't know what will happen? It'll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

If you really want to know you can. Basically in most cases it depends on the compiler. Sometimes the hardware. The point is that you should not expect any specific behavior because the standard doesn't specify one

[–] BatmanAoD@programming.dev 6 points 10 months ago

The standard differentiates between "unspecified" behavior, which is as you describe, and "undefined" behavior, which may be completely nondeterministic at runtime.

[–] BehindTheBarrier@programming.dev 1 points 10 months ago* (last edited 10 months ago)

And that's is the part that irks me a little. How should I expect anything when I don't expect the undefined behavior to begin with?

Say I manage to accidentally do something undefined, I do some math incorrectly on some index, and try to read out of bounds on an array that didn't implement bound guards. Now already it's my fault for several reasons, but in a complex project what the array is, and the details of the array may be "vague", especially if it's not something you did yourself in the project. So as a scenario, it's not completely out there. (some other dev knew the index was "always" right, and did premature optimization and used unguarded arrays instead) Still completely avoidable, but it can happen.

But if only an edge case actually leads to an out of bound read, the problem will probably never happen where the issue is. An experienced dev might never step into this mess, but sometimes this happens when other people change up what others did. I've had similar problems at my workplace, just not with undefined behavior as a result. At the end of the day, you sitting there with hard to know issues that have hard to know consequences.

This doesn't require a special programming language to solve, it just requires a guarded array first and foremost, tests and good reviews might see the bug as well before production. Which in C++ we were taught about from the beginning. If performance actual was a problem, then I guess we'd maybe still end up with this bug in the example. But my point is something along the lines of, all the good practice comes down to the choices of the individual developer. And the choices of one, also affects the next one.

If we could instead place those choices a step up in the chain however. Have the language enforce safety, unless you specifically say you need the be unsafe. So in my example, other the code would be safe already or someone threw and unsafe block to do their "fast" read of the array. In one case, I'll make a crash due to a bad read, the other I'll have to really evaluate why this is unsafe to begin with and apply extra caution. That extra caution goes away when everything is unsafe. Kinda like a small PR will have 15 comments, a huge PR will have less. You won't dedicate your all for every line of code, but if a line is tagged "unsafe" you sure as hell will.

Nothing is a magic solution to everything, and unsafe array reads are just a simple example of fucky behavior. I'm not sure if it still stands, but even something like this was/is undefined in C++

a[i] = i++;

That is to me something you quickly can forget about. And it happens because of compiler optimization that happens even if it breaks the code, because normally the index in the array should be a different variable. Again, here is something that should have obviously stopped me. If the compiler still follows through (I'm sure there warnings for it) then it's just letting me do an error no one should be allowed to. There is no reason this should ever compile.

If we cna do that for everything at the language level, it's a win in my book.

[–] bluGill@kbin.social 1 points 10 months ago (1 children)

Easy to say, but in the real world those are things you don't do so who cares? You mostly hear about it from people who use other languages and want to pick on C

[–] sugar_in_your_tea@sh.itjust.works 1 points 10 months ago

I think there's a much higher chance of running into UB on C++ vs C due to the complexity of the language. That's why I don't touch C++ and only use C if a higher level language isn't available. I can understand the C language in its entirety, whereas that's really not feasible with C++, especially at the edges.

So I think it's absolutely fair criticism of C++, but a little tired for C.

[–] SorteKanin@feddit.dk 8 points 10 months ago (2 children)

What problem do you think that undefined behavior poses?

Not sure exactly what you mean, could you elaborate or rephrase? What problem does it not pose? I mean any program with undefined behaviour is basically by definition wrong. Avoiding undefined behaviour is definitely a good thing.

[–] bluGill@kbin.social -2 points 10 months ago (1 children)

Those programs are wrong already. you can insert lots of checks and slow down correct code, but that results are still wrong as the code has a bug.

[–] SorteKanin@feddit.dk 3 points 10 months ago (2 children)

What do you mean wrong "already"?

[–] lysdexic@programming.dev -1 points 10 months ago (1 children)

What do you mean wrong “already”?

This is one of the problems in these discussions about undefined behavior: some people feel very strongly about topics they are entirely unfamiliar with.

According to the C++ standard, "undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data." Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

[–] SorteKanin@feddit.dk 2 points 10 months ago (1 children)

some people feel very strongly about topics they are entirely unfamiliar with.

Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

Sure, sometimes use of undefined behaviour works, but this is more dumb luck than a rule of thumb that you should use. The idea of "it's undefined behaviour but it works when I test it so it's fine" is downright dangerous. That kind of careless attitude might be okay for your hobby projects with low stakes, but for any serious professional software development, you're setting a landmine for yourself and/or your coworkers, employer and users.

Undefined behaviour might work when you test it and it might work when you run it the 1000th time. At the same time it may fail on the 1001st run and it can also easily completely fail when compiling again or simply compiling with a different compiler version. Undefined behaviour is not predictable and is always wrong.

[–] lysdexic@programming.dev -1 points 10 months ago (1 children)

Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

If you had half the experience you claim to have, you'd know that code that triggers UB is broken code by definition, and represents a bug that you introduced.

It's not the language's fault that you added bugs to the code. UB is a red herring.

Sure, sometimes use of undefined behaviour works (...)

You missed the whole point of what I said.

By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it's up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.

Thus, code with UB is broken code, and if your PR relies on UB then you messed up.

Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?

[–] SorteKanin@feddit.dk 2 points 10 months ago (1 children)

It’s not the language’s fault that you added bugs to the code.

Nobody's perfect and time has shown multiple time that you can't trust human beings with memory safety. I.e. the whole 70% of bugs being memory safety bugs thing. Adding bugs to the code isn't the language's fault, but you can't blame a human being (even experts) to do it.

It is however the language's fault to allow UB in the first place. And it's possible to entirely avoid UB in (safe) Rust. So we've seen that the possibility of undefined behavior is not necessary for the vast major of programming. So I would definitely say it's C and C++'s "fault" for allowing UB in the unrestricted way that it does.

Am I blaming those languages? Nah, it was a different time. We didn't have the technology we have now. But going forward there's no reason to use unsafe languages in greenfield projects. We should move forward with safe languages.

[–] lysdexic@programming.dev -1 points 10 months ago* (last edited 10 months ago)

Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety.

That's perfectly fine. That's not a problem caused UB, or involving UB.

Again, UB is a red herring.

It is however the language’s fault to allow UB in the first place.

It really isn't. Again, mindlessly parroting this doesn't give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.

Am I blaming those languages? Nah, it was a different time.

It really isn't. It's a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.

I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they're talking about.

[–] bluGill@kbin.social -2 points 10 months ago (2 children)

what is the usecase for going beyond maxint? Sure I can make it defined, but your program will have a bug if you do it. Defined just means platforms with a different behavior have to insert checks all over for something that rarely haypens

[–] SorteKanin@feddit.dk 7 points 10 months ago* (last edited 10 months ago)

Okay but I would much rather deal with a defined bug than an undefined one. A defined bug is still a bug, but at least it is predictable. A bug from undefined behaviour is chaos and could do conceivably anything.

A defined bug is at least somewhat limited in what it can do. In Rust, many of those cases would panic for instance. That's much better than, say, continuing execution with garbage data.

[–] lysdexic@programming.dev 2 points 10 months ago

what is the usecase for going beyond maxint?

There are many examples of applications that leverage integer overflow, either wrapping around or saturating values.

[–] lysdexic@programming.dev -5 points 10 months ago

Not sure exactly what you mean, could you elaborate or rephrase?

There is nothing to rephrase. I asked what problem do you think that undefined behavior poses. That's pretty cut-and-dry. Either you think undefined behavior poses a problem, and you can substantiate your concerns, or you don't and talking about undefined behavior being a concern is a mute point.

[–] ferralcat@monyet.cc 5 points 10 months ago (2 children)

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as "easy" though. Its easy to write code. It's hard(er) to make mistakes.

I kinda figure there's a bunch of systems programmers with their heads up their asses who would never be caught dead writing in an "easy" language though, so it couldn't go that way.

(I got bored and started skimming halfway though this article, but it's neat to hear about up and coming languages I'll never use at the end)

[–] sugar_in_your_tea@sh.itjust.works 2 points 10 months ago

But it's not easy. Understanding how memory works isn't easy, and satisfying the borrow checker is even harder. There are quite a few things that the borrow checker rejects that are completely fine, so you also may need to relearn some idioms.

Perhaps it would be better to market it as encouraging "sustainable" code. By that I mean:

lower chance of introducing concurrency bugs if you stick to safe rust
smother, safer refactors due to the type system and borrow checker
better long term performance because memory related performance issues are more obvious
strong nudge toward smaller structures because a lack of inheritance makes massive structures more of a pain to deal with

And so on. It encourages a more sustainable codebase, though you'll pay for that upfront.

[–] lysdexic@programming.dev 1 points 10 months ago

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I agree, but I don't think the problem is marketing. The problem is how some elements of Rust's community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that's not Rust. It goes well beyond a cargo cult mentality, and it's sad that a fine technology is dragged through the mud by those who were expected to show its value.

[–] noctisatrae@beehaw.org 3 points 10 months ago (2 children)

TL;DR Linkedin clickbait

I did read the article and it’s maybe it’s just me being a bitter, spiteful & petulant being, obnoxious to talk with but this article sucked. Every point ranged hollow.

It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.

The goal of MSLs is to reduce UB, and Rust want to do that but keep the speed and the productivity.

Of course, at some point you may need some C/C++ because it’s the cornerstone of modern programming but what you are calling with FFI are audited, open-source libraries so memory leaks/undefined behaviour is minimised.

Rust is implemented in Rust so FFI is greatly minimised if we follow the logic of the blogger.

[–] BatmanAoD@programming.dev 5 points 10 months ago (1 children)

the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.

Are you...aware of who the author is? He literally co-wrote The Book, aka The Rust Programming Language.

[–] lysdexic@programming.dev 4 points 10 months ago (1 children)

It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.

You're talking about Steve Klabnik, a guy known for being one of the authors of The Rust Programming Language and the guy who literally ran the @rustlang Twitter account.

[–] noctisatrae@beehaw.org 1 points 10 months ago (1 children)

Doesn’t change the overall quality of the article ?

[–] lysdexic@programming.dev 2 points 10 months ago (1 children)

Doesn’t change the overall quality of the article ?

I'm sorry, but I'm afraid the article is quite good.

[–] noctisatrae@beehaw.org 1 points 10 months ago

Why? I’m eager to learn.

Rust

Wormhole