Earlier quoted context omitted.
One can look at the source code to a program, the libraries it uses, the compiler for the language, and the ISA spec for the machine language the compiler generates. You can know that there are no hidden unspecified quantities because programs can't work without being specified. When you get down to the microcode of the CPU that implements the ISA you might have an issue if it's ill-specified. You might be talking ab…
> because programs can't work without being specified. Someone hasn't read the C spec, with all its specified as undefined behavior. Programs working on real systems is very different from those systems being formally specified. I suspect that if you only had access to the pile of documentation and no real computer system - if you were an alien trying to reconstruct it, for example - you'd hit serious problems.
All behavior in an implementation can be teased-out if given sufficient time.
> if you were an alien trying to reconstruct it, for example - you'd hit serious problems.
I can't speak to alien minds. Considering the feats of reverse-engineering I've seen in the IT world (software security, semiconductor reverse-engineering) or cryptography (the breaking the Japanese Purple cipher in WWII, for example) I think it's safe to say humans are really, really good at reverse-engineering other human-created systems from close-to-nothing. Starting with documentation would be a step-up.