john cannot load hashes with \r in salt, rejected in loader.c

$ python -c 'import crypt; print crypt.crypt("123456", "$1$\r")' > t2.pw
$ hd t2.pw
00000000  24 31 24 0d 24 34 75 41  51 76 6a 46 41 63 30 53  |$1$.$4uAQvjFAc0S|
00000010  4e 59 35 62 4a 57 57 5a  61 76 2f 0a              |NY5bJWWZav/.|

$ john --show=types-json t2.pw
[{"lineNo":1,"ciphertext":"$1$","consistencyMark":3}]

$ python -c 'import crypt; print crypt.crypt("123456", "$1$abcdefg\r")' > t2.pw
$ hd t2.pw
00000000  24 31 24 61 62 63 64 65  66 67 0d 24 69 59 65 51  |$1$abcdefg.$iYeQ|
00000010  4a 71 52 6c 32 4b 49 37  54 78 51 35 39 74 32 54  |JqRl2KI7TxQ59t2T|
00000020  73 2f 0a                                          |s/.|

$ john --show=types-json t2.pw
[{"lineNo":1,"ciphertext":"$1$abcdefg","rowFormats":[]}]

\r is replaced with \0, so john truncates hash at the first appearance of \r. It affects all hash formats that have salt as is and allow binary chars. I don't know if such hashes exist in the wild.

Start in loader.c and reproduce the issue with the two Python crypt commands and john --show=types-json shown in the report. Trace how carriage returns are handled while loading hashes; done means the full ciphertext is retained instead of being truncated at \r, with the reported formats still loading correctly.