mirror of https://git.musl-libc.org/git/musl
Browse Source
unfortunately, a large portion of programs which call crypt are not prepared for its failure and do not check that the return value is non-null before using it. thus, always "succeeding" but giving an unmatchable hash is reportedly a better behavior than failing on error. it was suggested that we could do this the same way as other implementations and put the null-to-unmatchable translation in the wrapper rather than the individual crypt modules like crypt_des, but when i tried to do it, i found it was making the logic in __crypt_r for keeping track of which hash type we're working with and whether it succeeded or failed much more complex, and potentially error-prone. the way i'm doing it now seems to have essentially zero cost, anyway.rs-1.0
1 changed files with 2 additions and 5 deletions
Loading…
Reference in new issue