jas88 at cam.ac.uk
Fri Mar 10 12:12:53 GMT 2000
On Fri, 10 Mar 2000, Peter Samuelson wrote:
> [James Sutherland]
> > Obviously, if crypt() CAN return NULL, for whatever reason, then it
> > must be properly handled and checked for.
> True -- unless the only time it will return NULL is for invalid input.
> Then it is sufficient to verify that it will never be given invalid
> input. In the case of crypt(), that shouldn't be too hard.
>From a quick look at the UFC implementation for glibc, I can't see any
reason why the code would return NULL. ALL the workspace is static (for
performance reasons, I suspect). Also, there aren't really any invalid
arguments: you just pass two string pointers. Any string will do; if the
string is too short, it is padded with nulls. If the pointer you pass is
invalid, things go pear-shaped (it just calls strncpy() cast to void!) but
it still can't return NULL. The return value is ALWAYS a pointer to the
static results buffer, if the function returns at all (rather than
The one exception might be if MD5 passwords are being used - I haven't
looked into that implementation yet. So, either the original problem is
due to a different implementation of crypt, or MD5 passwords.
Alex, which crypt() implementation are you using?
More information about the samba-technical