Comment by NewJazz
2 days ago
Which is notable because musl is more known for adhering to the spec to the point where they break programs that assume nonstandard behavior.
2 days ago
Which is notable because musl is more known for adhering to the spec to the point where they break programs that assume nonstandard behavior.
> adhering to the spec
Pedantic, but more "author's understanding of the spec" which isn't always correct.
> assume nonstandard behavior
I go back and forth on this one (spec vs standard behavior). It feels like at some point the most widely used impl -is- the spec, as we've seen in other places (web standards).
The spec is pretty unambiguous here: https://pubs.opengroup.org/onlinepubs/9799919799/functions/c...
> Upon successful completion, crypt() shall return a pointer to the hashed password [...]. Otherwise, it shall return a null pointer and set errno to indicate the error.
You need to add that the spec _also_ only defines a singular error state, that isn't applicable here.
> The crypt() function shall fail if:
> [ENOSYS]
> The functionality is not supported on this implementation.
1 reply →
To the best of my knowledge, only OpenBSD and Fedora have a crypt(3) that returns NULL. Everybody else returns a string starting with "*" on error.
For example on Debian the manpage says:
> Upon error, crypt_r, crypt_rn, and crypt_ra write an _invalid_ hash to the output field of their _data_ argument, and crypt writes an invalid hash to its static storage area. This string will be shorter than 13 characters, will begin with a ‘*’, and will not compare equal to _setting_.