Skip to main content
dcurran2
dcurran2
Associate III
June 21, 2013
Question

stm32f2xx USB potential bug

  • June 21, 2013
  • 5 replies
  • 1040 views
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

    This topic has been closed for replies.

    5 replies

    dcurran2
    dcurran2Author
    Associate III
    June 21, 2013
    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
    alexandr
    Associate II
    June 21, 2013
    Posted on June 21, 2013 at 17:04

    Downstreaming cycle usially works faster then upstreaming.

    dthedens23
    dthedens23
    Associate
    June 21, 2013
    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
    billr1
    Explorer
    June 23, 2013
    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
    dcurran2Author
    Associate III
    June 24, 2013
    Posted on June 24, 2013 at 17:47

    same 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 

     

    Terms & ConditionsAccessibility statement