stm32f2xx USB potential bug

[dcurran2]

Posted on June 21, 2013 at 13:59 search for CBW_CB_LENGTH typedef union _USBH_CBW_Block {   struct __CBW   {     uint32_t CBWSignature;     uint32_t CBWTag;     uint32_t CBWTransferLength;     uint8_t CBWFlags;     uint8_t CBWLUN;     uint8_t CBWLength;     uint8_t CBWCB[16]; }field;   uint8_t CBWArray[31]; }HostCBWPkt_TypeDef; both are used in the code as follows       for(index = CBW_CB_LENGTH; index != 0; index--)       {         USBH_MSC_CBWData.field.CBWCB[index] = 0x00;       }    lint produces the following Warning 661: Possible access of out-of-bounds pointer (1 beyond end of data) by operator '[' [Reference: file ..\..\STM32_USB_HOST_Library\Class\MSC\src\usbh_msc_scsi.c: lines 307, 309] anyone know why the code has been written this way

[dcurran2]

Posted on June 21, 2013 at 14:26 anyone know why this has been done as follows       for(index = USBH_MSC_CSW_LENGTH; index != 0 ; index--)         {           USBH_MSC_CSWData.CSWArray[index] = 0;         } rather than   for(index = 0; index < USBH_MSC_CSW_LENGTH; index++)

[alexandr]

Posted on June 21, 2013 at 17:04

Downstreaming cycle usially works faster then upstreaming.

[dthedens23]

Posted on June 21, 2013 at 17:38

or use memset   with argument of sizeof() because the compiler often does not lie about sizeof()

[billr1]

Posted on June 23, 2013 at 21:36

Regardless of why it was written the way it was, it certainly looks like a bug to me. It should be:

  for(index = CBW_CB_LENGTH-1; index !=0; index--)As originally written it will overwrite the next byte in memory which may or may not cause problems, depending on what is sitting there. 

[dcurran2]

Posted on June 24, 2013 at 17:47same could apply to

USBH_MSC_CSW_LENGTH

I only found and bothered about these as I use lint on all my projects and was doing the preparation before a peer review It doesnt seem to affect the performance of my USB functionality but the code maybe doesnt do what the author intended