then again, who needs reveng when you can use said LLMs to write new software "just in time" with the same API.
reveng also was one of those industries that always had a very suspicious crowd of people - i dont mean malicious, i mean... a lot of them drew a disturbing amount of pleasure from doing incredibly labourious work, sort of like someone who enjoys putting together an airfix model over many months with a microscopic brush and tweezers.
so i wonder if a lot of them perversely enjoy starting at reams of bytes and putting together this 10,000 piece puzzle, and having an llm solve it for them is a deep affront to their tastes.
That said there are probably ways a LLM could improve a decompiler in a way that does not impact its correctness. Like deriving class and variables names based on context, when symbols are missing or obfuscated.
If your function gets ownership of, or an exclusive reference to an object, then you know for sure that this reference, for as long as it exists, is the only one in the entire program that can access this object (across all threads, 3rd party libraries, recursion, async, whatever).
References can't be null. Smart pointers can't be null. Not merely "can't" meaning not allowed and may throw or have a dummy value, but just can't. Wherever such type exists, it's already checked (often by construction) that it's valid and can't be null.
If your object's getter lends an immutable reference to its field, then you know the field won't be mutated by the caller (unless you've intentionally allowed mutable "holes" in specific places by explicitly wrapping them in a type that grants such access in a controlled way).
If your object's getter lends a reference, then you know the caller won't keep the reference for longer than the object's lifetime. If the type is not copyable/cloneable, then you know it won't even get copied.
If you make a method that takes ownership of `self`, then you know for sure that the caller won't be able to call any more methods on this object (e.g. `connection.close(); connection.send()` won't compile, `future.then(next)` only needs to support one listener, not an arbitrary number).
If you have a type marked as non-thread safe, then its instances won't be allowed in any thread-spawning functions, and won't be possible to send through channels that cross threads, etc. This is verified globally, across all code including 3rd party libraries and dynamic callbacks, at compile time.