On 2023-09-02 21:23, cielesti wrote: > 2) (crypt "a" "$0$") returns "$0UqSJBCvZvN." > 3) (crypt "a" "$9$") returns "$9SxH5/IxLdbI" > > With TXR 278 that is in Alpine's package repo, those function calls error out as expected. By the way, those function calls should not have been erroring out. There is a funny/strange story behind that, which revolves around how I totally confused myself one day, just before the start of the pandemic: commit c3a0ceb2cea1a9d43f2baf5a2e63d0d712c8df19 Author: Kaz Kylheku Date: Fri Feb 14 21:55:24 2020 -0800 crypt: harden against crashes. This went into TXR 233. I was experimenting with crypt code and somehow fooled myself into believing a falsehood: that the crypt (at least on Glibc) lacks robustness and will segfault on bad inputs. To protect the TXR Lisp programmer against this, I coded a validation of the salt argument. This checked the salt for all the supported syntaxes like $6%, and valid DES characters and such. If the syntax didn't validate, my crypt_wrap function itself would throw the error exception, without ever calling crypt or crypt_r. In October 2022, I revisited the issue due to some Usenet discussions about crypt. Try as I might, I could not reproduce the problem which motivated the above commit---and the commit mentioned no repro steps. I studied the source of several versions of the glibc crypt, to no avail. On Hallowe'en morning, removed the code: commit 00d7b468e94d23646bb58b1774f5bec33b7c9fb1 Author: Kaz Kylheku Date: Mon Oct 31 07:18:41 2022 -0700 crypt: remove dubious validator. [...] And so, on this Halowe'en, we exorcise the ghost that has been haunting the crypt. That went into TXR 284. So after that, those tests would not fail any more on Musl.