Building -current from a day or so ago on arm32 with 2.7.2 (still trying to
bootstrap over to EGCS w/ static libs):

cc  -O2 -Werror -Wall -I. -I../../../../arch -I../../../.. -nostdinc -DFOOTBRIDGE -DEBSA285 -DSHMMAXPGS="0x400" -DMEMORY_DISK_HOOKS -DPMAP_STATIC_L1S="0x80" -DDIAGNOSTIC -DPOSTMORTEM -DMAXUSERS=8 -D_KERNEL  -Darm32 -Wcomment  -c ../../../../dev/usb/usb_subr.c
cc1: warnings being treated as errors
../../../../dev/usb/usb_subr.c: In function `usbd_find_idesc':
../../../../dev/usb/usb_subr.c:321: warning: `curaidx' might be used uninitialized in this function
*** Error code 1

Stop.

The following patch clears it up:

--- /usr/src/sys/dev/usb/usb_subr.c.orig	Sat Dec 12 01:17:36 1998
+++ /usr/src/sys/dev/usb/usb_subr.c	Sat Dec 12 01:17:41 1998
@@ -318,7 +318,7 @@
 	char *p = (char *)cd;
 	char *end = p + UGETW(cd->wTotalLength);
 	usb_interface_descriptor_t *d;
-	int curidx, lastno, curaidx;
+	int curidx, lastno, curaidx = 0;
 
 	for (curidx = lastno = -1; p < end; ) {
 		d = (usb_interface_descriptor_t *)p;

# eop

Looking at the code, it seems that while the logic is obviously intended to
initialize 'curaidx' to 0 before it is used, that is not provably the case.

Another warning in ugen.c:

cc  -O2 -Werror -Wall -I. -I../../../../arch -I../../../.. -nostdinc -DFOOTBRIDGE -DEBSA285 -DSHMMAXPGS="0x400" -DMEMORY_DISK_HOOKS -DPMAP_STATIC_L1S="0x80" -DDIAGNOSTIC -DPOSTMORTEM -DMAXUSERS=8 -D_KERNEL  -Darm32 -Wcomment  -c ../../../../dev/usb/ugen.c
cc1: warnings being treated as errors
../../../../dev/usb/ugen.c: In function `ugenpoll':
../../../../dev/usb/ugen.c:884: warning: `sce' might be used uninitialized in this function
*** Error code 1

Stop.

This one appears more serious. For now I am using this (dangerous) patch:

--- /usr/src/sys/dev/usb/ugen.c.orig	Sat Dec 12 01:32:32 1998
+++ /usr/src/sys/dev/usb/ugen.c	Sat Dec 12 01:32:49 1998
@@ -881,7 +881,7 @@
 {
 	struct ugen_softc *sc = ugen_cd.cd_devs[UGENUNIT(dev)];
 	/* XXX */
-	struct ugen_endpoint *sce;
+	struct ugen_endpoint *sce = 0;
 	int revents = 0;
 	int s;
 

# eop

The danger is that, if I read the rest of the function correctly, the first
use of 'sce' will be to access a member of it, so it will SEGV if executed.

The rest of the kernel builds OK and it runs, probably because I have no USB
devices actually plugged in. I do have a Belkin 3-button USB mouse handy, so
if anyone wants me to conduct some tests, just say so.

Todd Whitesel
toddpw @ best.com