Hi,
I'm just implementing the Keil HID sample code, but I found some strange things even the compiler complains about:
In usbcore.c there are some variables used without being set before. The variables are "alt" in USB_SetConfiguration() and "msk", "old", "alt" and "ifn" in USB_SetInterface().
__inline BOOL USB_SetConfiguration(void) { USB_COMMON_DESCRIPTOR *pD; DWORD alt, n, m; : case USB_INTERFACE_DESCRIPTOR_TYPE: alt = ((USB_INTERFACE_DESCRIPTOR *) pD)->bAlternateSetting; break; case USB_ENDPOINT_DESCRIPTOR_TYPE: if (alt == 0) { : } : }
The code at USB_ENDPOINT_DESCRIPTOR_TYPE is executed when "alt" is 0 by chance only and setting "alt" in USB_INTERFACE_DESCRIPTOR_TYPE has no effect as "alt" is an auto-variable loosing it's contents after USB_SetConfiguration() is finished.
USB_SetInterface() shows similar things.
The source code does work in my environment, but I'm anxious that this is by chance only.
Could anybody explain me how to come to a more reliable solution?
BTW: Code parts like
(BYTE *) pD += pD->bLength;
in a sample code scare me even after more than 20 years C programming (Realview complains as well).
Regards Herbert
If a good lint tool isn't an option, then it sometimes helps to see if the code can be compiled with alternative compilers since different compilers normally finds different things to complain about.
This is an ARM thread, but most code should be possible to compile with a 32-bit PC compiler (gcc, VC++, ...) if you just supply relevant header files. You will obviously not manage to link an ARM binary, but the results from compiling individual source files can be revealing. Note that some compilers requires full optimization for some warnings to be issued, i.e. when the compiler performs maximum flow analysis.