Panics _can_ sometimes conceptually share the same implementation as exceptions, but given that their usage is not the same, and the fact that the ecosystem doesn't use panics as exceptions, it's a bit of stretch saying they're "functionally" the same.
A bit like saying trains and chairs are functionally the same since they both can have wheels; when there's the crucial difference that chairs don't go choo-choo.
> given that their usage is not the same, and the fact that the ecosystem doesn't use panics as exceptions, it's a bit of stretch saying they're "functionally" the same.
No, these don’t matter. Every langage with exceptions uses them differently, that doesn’t make Python’s no-exceptions and Java’s exceptions.
Regardless of how it’s used, it either is or is not an exceptions system. That’s what “functionally” means.
For instance Go’s panics are an exceptions system, you can always recover() and handle the exception during its unwinding.
> A bit like saying trains and chairs are functionally the same since they both can have wheels
No, it’s like saying an HSR and an ore train are functionally similar, because both are trains even though they’re used differently, in different contexts, and with different performance profiles.
You put #[non_exhaustive] on a enum in Rust to force users matching on it to handle an "else"/"default" case, so that you can add more variants to this enum in the future without breaking their code.
It doesn't mean that the enum itself is non exhaustive: at any point in time when enum is defined, it defines all of its variants and any other value is still UB.
Right, the purpose of this annotation is to prevent humans from writing code that's going to break in the future not to prevent the compiler from optimising the code it sees in front of it right now today. Let's provide a little example.
Suppose I've written a library with a USFederalHoliday type, it's 2018 when I ship version 1, and so of course my library doesn't have Juneteenth because that's not a Federal Holiday. But I am aware that over the history of the US, new holidays get created, and so I add the annotation non_exhaustive. A program you wrote using this type in 2019 might have matches for NewYears, LaborDay, VeteransDay and all the others but because of non_exhaustive you're obliged to write a clause handling "other" possibilities, even though at the time there aren't any.
In 2021 I add Juneteenth to the enumeration, ship that as version 2, and your program still compiles with the new version. Juneteenth just matches the "other" case in any matches, Rust checked those are valid even when they were never used, now they're used. They might be wrong of course, Rust can't fix that.
Now, suppose your program prints the phrase "Congratulations on your new holiday" to stderr only if the other case matches.
When compiled against version 1, Rust's compiler is obliged to check that the syntax and semantics of your "print Congrats" stuff works but it is not obliged to actually emit code which can detect such a case and actually print the message because it can tell, at compile time, that version 1 of the library actually has no other cases you didn't handle. The "Congratulations" message may end up not even compiled into the program.
With version 2, the compiler can see that now Juneteenth is a USFederalHoliday and that isn't handled by your code, and so that "Congratulations" message might be used, and the message definitely goes in to the binary.
Now, the unsafe transformation of values from a non-Rust library could result in unexpected bit patterns for a type which claims to be USFederalHoliday, but Rust's compiler was never expecting to see such values. In safe Rust they can't happen and if you introduce them from unsafe Rust that's Undefined Behaviour. So despite the non_exhaustive annotation, the compiler needn't ensure that such bit patterns do something reasonable.
the root cause might be yocto which itself is very complex? xilinx just added its own layer on top when the board was made, and it stays un-updated for a few years, you got something initially working, and you need update it yourself after running its demos.
i use petalinux, not great not terribly bad either, I would say it's average.
I wouldn't be surprised if this were the case. IME you're better off either going from scratch, using gentoo, or using a different distro rootfs if they have appropriate binaries and just maintaining a custom kernel.
