openssh unix dev - Sep 2003 - Variable declarations in xcrypt.c

Hi All.
	I noticed that xcrypt.c now has some variable declarations after code
within a block (for some sets of #ifdef's).  Won't that choke some
compilers?  Should it do something like the attached?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: openbsd-compat/xcrypt.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/xcrypt.c,v
retrieving revision 1.4
diff -u -p -r1.4 xcrypt.c
--- openbsd-compat/xcrypt.c	6 Sep 2003 23:43:42 -0000	1.4
+++ openbsd-compat/xcrypt.c	8 Sep 2003 06:52:26 -0000
@@ -96,18 +96,25 @@ shadow_pw(struct passwd *pw)
 		pw_password = spw->sp_pwdp;
 # endif
 # if defined(HAVE_GETPWANAM) && !defined(DISABLE_SHADOW)
-	struct passwd_adjunct *spw;
-	if (issecure() && (spw = getpwanam(pw->pw_name)) != NULL)
-		pw_password = spw->pwa_passwd;
+	if (issecure()) {
+		struct passwd_adjunct *spw;
+
+		if (spw = getpwanam(pw->pw_name) != NULL)
+			pw_password = spw->pwa_passwd;
+	}
 # elif defined(HAVE_SECUREWARE)
-	struct pr_passwd *spw = getprpwnam(pw->pw_name);
+	if (spw != NULL) {
+		struct pr_passwd *spw = getprpwnam(pw->pw_name);
 
-	if (spw != NULL)
 		pw_password = spw->ufld.fd_encrypt;
+	}
 # elif defined(__hpux) && !defined(HAVE_SECUREWARE)
-	struct pr_passwd *spw;
-        if (iscomsec() && (spw = getprpwnam(pw->pw_name)) != NULL)
-                pw_password = spw->ufld.fd_encrypt;
+        if (iscomsec()) {
+		struct pr_passwd *spw;
+
+		if (spw = getprpwnam(pw->pw_name) != NULL)
+                	pw_password = spw->ufld.fd_encrypt;
+	}
 # endif
 
 	return pw_password;

Darren Tucker wrote:
>Hi All.
>	I noticed that xcrypt.c now has some variable declarations after code
>within a block (for some sets of #ifdef's).  Won't that choke some
>compilers?  Should it do something like the attached?
>  
>
This should work on all compilers.

Only aCC (HP) compiler fail on variable declaration with same name in blocks
inside switch statement, i.e.
switch (...) {
  ...
  case ... 
    {
       int var;
       ...
    }
  ...
  case ... 
    {
       int var; /* FAIL ON HP. work arround - to rename variable */
       ...
    }
  ...
}

On Mon, 8 Sep 2003, Darren Tucker wrote:
> Hi All.
> 	I noticed that xcrypt.c now has some variable declarations after code
> within a block (for some sets of #ifdef's).  Won't that choke some
> compilers?  Should it do something like the attached?
>
Well.. the first #ifdef will never be triggered with the second set.  You
can't set shadowed and HAVE_GETPWANAM.  So it should be safe as it is.
However maybe it should be an #elif instead of a #endif #if ..

- Ben