none
Convert 32 bit to 64 bit and handling size incompatibilities RRS feed

  • Question

  • Given the example

    vector<BYTE>  myVector;
    ... fill the vector with bytes
    Transmit( &myVector[0], myVector.size() );

    void Transmit( BYTE *pSrc, ULONG len )
    {
       ....
       WinUsb_WritePipe( ..., len, ... );
    }

    WinUsb_WritePipe only takes a ULONG. This is fixed regardless of 32/64 bit.

    Code compiles fine under 32 bit. Warnings under 64 bit about the size
    mismatch of myVector.size() and ULONG.

    Now the philisophical question. What is the best/accepted way to
    promote compatability?

    1) change Transmit( BYTE *pSrc, size_t len )
          assert(len < max ULONG )
          ....
          WinUsb_WritePipe( ..., ULONG(len), ... )

    2) use a function and modify the invocation
             template<typename T>
             ULONG Legacy32( T s )
                {
                  assert( s < max ULONG )
                 return ULONG(s);
                }

             Transmit( &myVector[0], Legacy32(myVector.size()) );
    3) ?? other options

    Thursday, April 11, 2013 9:45 PM

Answers

  • Transmit( BYTE *, size_t) and cast within the function. you can have a check for truncation, something like this

    #if _WIN64

    if (Size > ULONG_MAX) { // DbgBreakPoint(); or whatever you want }

    #endif

    in one specific spot and handle it. clearly only a problem if you have more than 4 GB of data in your vector.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, April 15, 2013 5:32 PM

All replies

  • 1) change Transmit( BYTE *pSrc, size_t len )

          assert(len < max ULONG )
          ....
          WinUsb_WritePipe( ..., ULONG(len), ... )

    2) use a function and modify the invocation
             template<typename T>
             ULONG Legacy32( T s )
                {
                  assert( s < max ULONG )
                 return ULONG(s);
                }

    The main philosophical question aside, I hope you're aware
    that those assert macros will only be functional in a Debug
    build. You will have no checks from them in a Release build.

    - Wayne

    Thursday, April 11, 2013 10:56 PM
  • I think that the first variant is acceptable if you do not want to make changes in multiple places. If changes are allowed, then consider this option as well: ‘Transmit(const vector<BYTE> & v)’.

    Friday, April 12, 2013 5:23 AM
  • Yes I'm aware of that. Given that we only transmit in sizes of less than 10K I don't expect any issues. I would really love to have a compile time check but that's not going to happen.
    Friday, April 12, 2013 12:27 PM
  • Not all locations that call Transmit store the buffer in a vector. It's locations that do that are causing problems. We could implement a Transmit( const vector<BYTE> &v) but it would simply turn around and call the Transmit( BYTE *, ULONG ). I would still be left with the problem of downsizing the vector.size() to a ULONG.

    My philosophical debat can be boiled down to

    Transmit( BYTE *, ULONG );  // can't transmit more than 4GB. Interface documents the restriction

    Transmit( BYTE *, size_t );   // surprise truncation in 64bit mode. Rely on comments in the header

    Friday, April 12, 2013 12:42 PM
  • Hi ,

     

    I think your issue should be raised in the  Windows WDK and Driver Development Forum

     I believe they will know more information of this issue than us, and I will move this one to that forum.

     

    Thanks for your understanding,

     

    Best regards,

    Jesse


    Jesse Jiang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, April 15, 2013 7:25 AM
  • Transmit( BYTE *, size_t) and cast within the function. you can have a check for truncation, something like this

    #if _WIN64

    if (Size > ULONG_MAX) { // DbgBreakPoint(); or whatever you want }

    #endif

    in one specific spot and handle it. clearly only a problem if you have more than 4 GB of data in your vector.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, April 15, 2013 5:32 PM
  • Thanks. That's what we did. We were a little more harsh than a debug break. We took the USB device offline, after logging the appropriate message.
    Tuesday, April 16, 2013 1:04 PM