diff options
author | Rich Felker <dalias@aerifal.cx> | 2012-08-09 20:47:17 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2012-08-09 20:47:17 -0400 |
commit | b3c4cc121f70faea45389fe7ddc1127ed5cbd8bb (patch) | |
tree | 3bebd913d79b7acac599853a2e82c0831421ae77 /src/string/strchrnul.c | |
parent | ae0b9da48c91087c5ab78e4918deb69665d0ccc6 (diff) | |
download | musl-b3c4cc121f70faea45389fe7ddc1127ed5cbd8bb.tar.gz musl-b3c4cc121f70faea45389fe7ddc1127ed5cbd8bb.tar.xz musl-b3c4cc121f70faea45389fe7ddc1127ed5cbd8bb.zip |
make crypt return an unmatchable hash rather than NULL on failure
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.
Diffstat (limited to 'src/string/strchrnul.c')
0 files changed, 0 insertions, 0 deletions