Subject: Re: Warnings in nfsv3 code--buggy gcc?
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: tech-kern
Date: 03/29/1996 11:27:23
>> ../../../../nfs/nfs_socket.c: In function `nfs_timer':
>> ../../../../nfs/nfs_socket.c:1243: warning: `cur_usec' might be used uninitialized in this function

> I had to commmit a bit of evil to avoid a similar warning in some
> other code on the sparc...If you initialize the variable with "0" or
> whatever before it's used, the warning will go away...

Well, yes.  But that's just papering over the real bug, which is that
gcc is simply wrong.

At least if the nfs_socket.c in question is anything like the one I
have online.  The one I have is

/*      $NetBSD: nfs_socket.c,v 1.26 1996/02/25 17:47:26 fvdl Exp $     */

and has MD5 checksum b4e3e01f62f26c3fb595293282ba702e.  In this
nfs_socket.c, line 1243 is the declaration "u_quad_t cur_usec;".
The code in question looks like

void nfs_timer(void *arg) {
	...other declarations...
	u_quad_t cur_usec;
	s = splsoftnet();
	...big for loop, cur_usec not even mentioned...
#ifdef NFSSERVER
	if (...) { ... } /* cur_usec not mentioned in here */
	cur_usec = ...something...;
	for (...;...;...) { if (... && ... <= cur_usec) ...; }
#endif
	splx(s);
	timeout(nfs_timer,(void *)0,nfs_ticks);
}

The entire file contains no other occurrences of the character sequence
"cur_usec".  It occurs exactly three times: the declaration, the
assignment, and the comparison.  I'm sorry, but there is just no excuse
at all for gcc to think that cur_usec might be used uninitialized in
there.  This is a gcc bug.

Or else, of course, the code that provoked the complaint doesn't match
the code I have online.

> For the record, I think that this sort of warning from gcc is
> completely bogus.

This particular warning may be broken, but this _type_ of warning is
useful.  It's occasionally caught bugs for me.  (I'd say about 50% of
the -Wuninitialized warnings I see are for real and the other 50% are
cases where gcc just can't realize that the variable is always
initialized, in which case adding an obvious initialization is the
appropriate treatment.

At least that's my opinion, for what it's worth.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu