Closed beltram closed 2 years ago
If the assembly file is guaranteed to work on the other targets without any weird quirks or exceptions, then I think we can simply add them to the list of supported targets.
Overall, the asm-hashes
crates were intended as experimental and we plan to deprecate them in favor of using inline assembly.
Given the fact those target are going to be aggressively deprecated in a few times I think I'll simply fix by using force-soft
.
Thanks for the answer
Note that you do not need the force-soft
feature. The asm
backend is disabled by default and should not be enabled by library crates. If something in your dependency tree unconditionally enables it, ask them to fix it.
Hi, I recently experienced a runtime error (null pointer dereference) on Android after bumping the sha2 crate from
0.10.2
to0.10.3
. It is very likely related to #388 which, for very good reasons, preventsasm
on untested targets.I get that I can workaround by using the
force-soft
feature. The thing is,asm
happened to work on other targets [i686
,armv7
]. And I would like to keep the performance benefits of assembly.So what I propose is to bring back this "accidental" support for other arch in the form of a
unchecked-asm
(orunsafe-asm
) feature (formd5
,sha1
,sha2
andwhirlpool
). It could be opted in by consumers just on the desired targets.What do you think ?