Minor fix to pass_check.c re string lengths

[Green, Paul]

The following change to source/passdb/pass_check.c makes the program a
little more consistent about declaring several temporary variables as
"fstrings" (which are 256 character temp strings).  There are several places
in pass_check.c where the "fstrcpy" macro is used to assign to these
variables, and it could overwrite storage without this fix.  I do not know
of any such instances, however.  I have made this change locally without any
problems (on the Stratus VOS operating system), although that should hardly
be considered authoritative, since some of the erroneous code is within
#ifdefs that we do not use.

The change for assigning a null character with \0 instead of 0 is just for
readability and purity.

If you grep pass_check.c for strcpy, you will see that it is inconsistent
about whether passwords must be stored in fstrings (256 chars) or pstrings
(1024 chars).  I have not attempted to change this, because I don't know
which is correct. I would say that the inconsistent use might come to light
if anyone ever has a password that exceeds the maximum length of an fstring.

This diff -u is against 2.2.1a.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.



--- 2.2.1>source>passdb>pass_check.c	Thu Aug 30 11:00:50 2001
+++ 2.2.1vos>source>passdb>pass_check.c	Thu Aug 30 11:02:44 2001
@@ -27,9 +27,9 @@
 extern int DEBUGLEVEL;
 
 /* these are kept here to keep the string_combinations function simple */
-static char this_user[100] = "";
-static char this_salt[100] = "";
-static char this_crypted[100] = "";
+static fstring this_user = "";
+static fstring this_salt = "";
+static fstring this_crypted = "";
 
 #ifdef WITH_AFS
 
@@ -690,7 +690,7 @@
 	struct passwd *pass = NULL;
 
 	if (password)
-		password[pwlen] = 0;
+		password[pwlen] = '\0';
 
 #if DEBUG_PASSWORD
 	DEBUG(100, ("checking user=[%s] pass=[%s]\n", user, password));