Comment by boomlinde

An interesting thing about C is that there is no guarantee that NULL dereferencing will "surface". It's undefined behavior.

NetBSD and libxcrypt both have similar workarounds. NetBSD has a paragraph on the reasoning.

   The behavior of crypt() on errors isn't well standardized.  Some imple-
   mentations simply can't fail (unless the process dies, in which case they
   obviously can't return), others return NULL or a fixed string.  Most
   implementations don't set errno, but some do.  Version 2 of the Single
   UNIX Specification (``SUSv2'') specifies only returning NULL and setting
   errno as a valid behavior, and defines only one possible error (ENOSYS,
   ``The functionality is not supported on this implementation.'') Unfortu-
   nately, most existing applications aren't prepared to handle NULL returns
   from crypt().  The description below corresponds to this implementation
   of crypt() only.  The behavior may change to match standards, other
   implementations or existing applications.

OpenBSD and glibc both have similar simple, stupid-free return value implementations. OpenBSD:

    The function crypt() returns a pointer to the encrypted value on success, and NULL on failure.

GNU:

    On success, a pointer to the hashed password is returned.  On
    error, NULL is returned.

The distro I use on the desktop uses libxcrypt, though. Probably more distros are. Its, NetBSD's and musl's workarounds probably make sense in some way if you have no clue what goes into your userland and are willing to write stupid software to accommodate for that.