regression in supported architectures

[beltram]

Hi,
I recently experienced a runtime error (null pointer dereference) on Android after bumping the sha2 crate from 0.10.2 to 0.10.3. It is very likely related to #388 which, for very good reasons, prevents asm 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 (or unsafe-asm) feature (for md5, sha1, sha2 and whirlpool). It could be opted in by consumers just on the desired targets.

What do you think ?

[newpavlov]

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.

[beltram]

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

[newpavlov]

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.