Slice to `[u8;4]`
Slice to `[u8;4]`
Posted Oct 4, 2024 8:19 UTC (Fri) by geert (subscriber, #98403)In reply to: Slice to `[u8;4]` by farnz
Parent article: A discussion of Rust safety documentation
Posted Oct 4, 2024 10:42 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
You're right - that's the other fun of using "clever" code, in that you can confuse someone trying to refactor it, and the compiler won't complain.
A better translation would be this Godbolt link, which makes the use of unsafe very clearly about not panicking on error, and uses safe functionality for all of the data transformation. It also makes it clear that this function should be marked as unsafe, since as a precondition it requires buf to be long enough.
Posted Oct 4, 2024 11:41 UTC (Fri)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Oct 4, 2024 11:55 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
The reason there's so much code for one asm instruction is that most of the code is concerned with things that asm doesn't care about - asm doesn't care if you're reading out of bounds (that's a CPU fault at worst, and a program bug at best), or if you're asking it to read from the "wrong" location, or a whole host of other things that programming languages care about.
And it's similar in size to the dance you need to do with standard C to get the same instruction.
Posted Oct 4, 2024 12:08 UTC (Fri)
by pizza (subscriber, #46)
[Link] (2 responses)
So... you're saying that the job _isn't_ done when the Rust compiler stops complaining, and that the resultant code might not actually _work_ even though the compiler "proved" it to be "correct"?
(Yeah, yeah, I know you're not one of the obnoxious evangelists making that idiotic claim, but I've been piled upon here multiple times here for making this point..)
Posted Oct 4, 2024 12:21 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
As with anything, it depends what you require the compiler to prove. My experience is that Rust code is more likely to use enums, structs and other such type system to make it impossible to represent impossible states, rather than clever code that allows for this sort of bug to slip past.
In other words, the problem here is clever code where you're trying to beat the optimizer, rather than trusting that the optimizer will get it right. And my experience of cheap coders (offshore outsourcing body shops) is that they trust the optimizer instead of trying to be clever, so they'll do the right thing in Rust; I have, however, had a pile-on for expressing that in the past.
Posted Oct 4, 2024 13:12 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
But isn't that *always* true? Just because the *maths* is correct, doesn't mean the *logic* is sound.
I have a production system that uses bell-curve statistics on a skewed distribution. It mostly works because the data is USUALLY a strong peak with a weak tail on one side. But feed it a double-peak, or a strong tail, and the results will be rubbish. That's a risk we've chosen to accept. The mathematical model is sound. It's just the fit to reality isn't quite right ...
Cheers,
Slice to `[u8;4]`
Slice to `[u8;4]`
About the new version: Wow, writing that much code to generate a function with a single asm instruction...
Slice to `[u8;4]`
Slice to `[u8;4]`
Slice to `[u8;4]`
Slice to `[u8;4]`
Wol