Hi Vincent, > Date: 2026-11-12 14:15:47+0100 > From: Vincent Lefevre > > On 2026-11-12 13:08:12 +0100, Alejandro Colomar wrote: > > > This means that when "$" is supported by some implementation, > > > the interpretation of the return value may be different from > > > what POSIX specifies. > > > > Kind of. They better don't deviate from it in non-confirming ways; > > one could argue that musl's "x" return value is indeed such a > > non-conforming return value, and a NULL return value would be better > > (both more conforming and safer). > > This is more complex. The issue is that in the past, crypt() seemed to > have been designed so that it could not fail (except in the case where > it wasn't providing any implementation, i.e. it was always failing), > so that applications did not expect a null pointer and some of them > still do not check this case. Hence the choice done my musl. It would be interesting to list all FOSS programs that forget to check for NULL, and perhaps talk to them to update their code. Cheers, Alex > Problems could be avoided only by writing more robust applications: > * They should have had a check for the null pointer. > * When a hash is obtained, applications should also check > whether the hash has the expected form (for instance, > the "*" returned by musl does not). > > -- > Vincent Lefèvre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon) --