Re:How I implemented my own crypto
by Ded7xSEoPKYNsDd on Thursday August 03, 2017 @06:05AM
(#14918282)
The ARM Architecture Reference Manuals are full of "if you do X, the instruction is UNPREDICTABLE".
Re:How I implemented my own crypto
by bandook_raja on Thursday August 03, 2017 @04:19AM
(#14917866)
> Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.
You just need to know your compiler flags/configuration to produce exact assembly output (if you want that). And about assembly not having UB, BSF and BSR are pretty good examples for that.
That just is quite ironic, because it is even version dependent across releases of the same compiler, which means anything fine tuned for version X can break on version X + 1, due to changes on the optimizer.
And I doubt anyone is regularly reviewing the produced Assembly every single time they change compilers.
Assembly doesn't have more than 200 documented cases that hardly any human is capable of remembering.
You could argue that each processor's errata is UB in assembly. I remember that programming for the XScale we had a whole manual of errata that we had to program around. Though because it's documented it's not "Undefined", it's just "Incorrect but we know how incorrect".
Re:How I implemented my own crypto
by TheAceOfHearts on Thursday August 03, 2017 @04:28AM
(#14917902)
Aren't all undocumented instructions / opcodes actually UB? If you execute an undocumented instruction the processor has to do something.
You can't really accidentally or unintentionally arrive at undefined behaviour in assembly language though. You would have to explicitly use an undocumented instruction or opcode and the result would probably be a hardware interrupt or exception every time.
Re:How I implemented my own crypto
by SAI_Peregrinus on Thursday August 03, 2017 @06:53AM
(#14918476)
Not quite every time though: https://github.com/xoreaxeaxeax/sandsifter
The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages.
Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded code and the beloved UB.
UB which doesn't exist in most languages, because their rather leave it implementation defined or lose the opportunity to target some strange CPU not able to support the language semantics.
Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.