This line renders wrong for David's name.

s/favour/favor/
(we use american english in the project)

Thank you for taking the time to review. This has been updated. In fairness, this example pre-dates the crypt_r in FreeBSD by 4+ years.

I will take care of the style (and strn*) items, please excuse.

With respect to the API, I think there's a good discussion to be had here.

It would seem that having the salt generation (and knowledge of what an appropriate salt is for the entire suite of algorithms supported by crypt) pushed into the consumer would be needlessly complex. It ossifies algorithm support all over the place.

This is not the only approach however, and perhaps we can take a page with the work done by the OpenBSD project in this space since the original patch was submitted:

https://www.tedunangst.com/flak/post/retiring-crypt
^ gives cert error, by intent

i.e. crypt_newhash and crypt_checkpass specifically.

Also, there's some old old discussion available on the mailing lists as well, if that interests you. I've linked into the thread here:

https://lists.freebsd.org/pipermail/freebsd-current/2014-March/048848.html

Thanks for the context. Is there some reason not to have the crypt functions to generate a salt on demand instead (e.g. when the passed salt is too short, which is something that we already will check, and the individual crypt function actually knows better)?

It worried me because with your new API, the callers are now required to do more work (allocating memory, check for the result, etc.).

I'm not sure, it sounds like a good idea. I feel like having crypt do that automatically would be pretty surprising though, there's no precedent? (There's also no precedent for crypt_makesalt, but there are a few crypt_gensalt implementations.)

With regard to the more work, perhaps that's also a benefit:

• For the memory allocation, the example code and the updated user-land could be easily simplified by allocating a static buffer of _PASSWORD_LEN, which would be no worse than the current crypt_data constraint. The salt will never be longer than the crypt_data buffer, by definition. The retry logic could be removed, and just fail in this case. This isn't great, but it should only hit this code path if the the ABI changes under the consumer, and should be a simple if. If clients wish to protect against ABI changes (what does that even mean?) with retry logic, they could - but perhaps it's wrong-headed to have that as I've provided it.
• For the format case, I think having feedback that a format isn't supported by the crypt implementation is valuable. I imagine most people (i.e. sysadmins) specifying the crypt format in a configuration file, and the consumer utility being agnostic. How would we otherwise signal an unsupported or invalid crypt request? I don't think returning a "default" hash is a good idea (if we simply extend crypt), and a DES crypt would be particularly damaging - but would be required for backward compatibility.

I think the format validation is a strong case for this. The crypt_newhash approach also allows to signal an invalid format, but doesn't differentiate a short buffer with an invalid format. What do you think?

Any thoughts on a sensible way to move this portion forward?

I would submit a crypt_newhash approach similar to that of OpenBSD, if that was agreed to be a sensible way to proceed.

why was previous char * enclosed in quotes, but not this one?

I'd combine these two statements, into:
Password hashing is different than a standard one way hash function in that it tries to make it difficult to recover a low-entropy

What should be used instead?

concerted that it's not listed as $digit$ or $digit[variant]$, because this means that we cannot have more than 10 variants.. as $11$ will match md5-crypt per this spec. We are already up to 6...

this should probably be removed, as the next paragraph's It is unclear.

again, next paragraph It isn't clear.

space between 3DES and comma.

was the addition of the semicolon intentional? this is usually left off and it looks like it may cause a compile error.

might want to make this a define, like SALTBUFFER or something to replace the SALTSIZE define. There was another location this size was used.