zlacker

His point seems to be the opposite, that "safety" should have a vaguer meaning in his opinion, and not the well established technical definition that the author clearly meant when he used the word.

>>a_hume+(OP)
Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.

>>LtWorf+k3
You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.

>>a_hume+T7
I think the word "safety" existed before rust…

>>LtWorf+8e
This has nothing to do with the common definition of "safety".Terms change their meaning based upon their use and context. The author has a clear use in mind - memory safety.

The rules of arugment existed long before the linux kernel. You don't get to change terms introduced within a arugment with a clear meaning because it helps you create a strawman. If you want to change the definition of a term mid arugment, you telegraph it. Once again, this is called conflation.

>>a_hume+T7
>when it had a clear meaning in its use

Thats not the issue though. It's that "safe" means something is actualy safe. My house isn't safe if its on fire, even if the house is in a safe neighborhood. Linus' claim is that "rust people" sometimes themselves conflate memory saftey with general code saftey, simply because "safe" is in the name. So much so that they will at times sacrifice code quality to achieve this goal despite (a) memory saftey not being real saftey and (b) there is no way to guarantee memory saftey in the kernel anyway. What he is saying is that "rust people" (whatever that means) are at times trading off real saftey or real code maintenance/performance for "rust saftey."

>a compiler - or language infrastructure - that says "my rules are so ingrained that I cannot do that" is not one that is valid for kernel work.

And

>I think you are missing just how many things are "unsafe" in certain contexts and cannot be validated.

>This is not some kind of "a few special things".

>This is things like absolutely _anything_ that allocates memory, or takes a lock, or does a number of other things.

>Those things are simply not "safe" if you hold a spinlock, or if you are in a RCU read-locked region.

>And there is literally no way to check for it in certain configurations. None.

You can judge wheter he is correct but he never said rust's saftey implies absolute saftey, only that some rust users are treating it that way by sacrificing the code for it. If that's the case then it makes a lot of sense to start using a more sensible word like "guaranteed" instead of safe. I think part of what contibutes to this idea is that "unsafe" code is written with the keyword "unsafe" as if code written not that way is safe, and code written with "unsafe" is bad. That's not to say that "unsafe" actually implies any of that - all it means is that it's not guaranteed to be memory safe - but according to Linus it creates a certain mentality which is incongruent with the nature of kernel development. And the reason for that is that safe and unsafe are general english words with strong connotations such as:

>protected from or not exposed to danger or risk; not likely to be harmed or lost.

>uninjured; with no harm done.

And for unsafe:

>able or likely to cause harm, damage, or loss