QT project and USB connection

Question

I have problems with FTD2xx driver. I'm using QT(C++) in Fedora 26 (64-bit) and the last version of FTD2xx for "2232H" device. Also the build method is:

qmake /Address/ProjectName.pro -r -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

Problem:

The FT_Status return 0(FT_OK) at ft_openex(....) command, but that return none_zero(FT_OK) for other functions of FTD2xx lib; A section of my code:

FT_HANDLE   ftH;
FT_STATUS   ftStatus;
ftStatus = FT_OpenEx(const_cast<char*>("MYDevName"), FT_OPEN_BY_SERIAL_NUMBER, &ftH);
std::cout<<"FTST open:"<< ftStatus<<std::endl;
char a[10];DWORD b;
ftStatus = FT_SetBitMode(&ftH,0xff,0);
std::cout<<"FTST RESET:"<< ftStatus<<std::endl;
ftStatus = FT_SetBitMode(&ftH,0xff,0x40);
std::cout<<"FTST SPEED:"<< ftStatus<<std::endl;
ftStatus = FT_Close(&ftH);
std::cout<<"FTST CLOSE:"<< ftStatus<<std::endl;

And output :
FTST open:0
FTST RESET:1
FTST SPEED:1
FTST CLOSE:1

ftStatus =1 ;means FT_INVALID_HANDLE.
and
Command <<rmmod ftdi_sio >> is using.
and
Lib directory: /dev/local/lib
and
QT setting:
LIBS += -L$$PWD/../../../usr/local/lib/ -lftd2xx
INCLUDEPATH += $$PWD/../../../usr/local/include
DEPENDPATH += $$PWD/../../../usr/local/include

Answer 1

The FT_HANDLE is an output parameter in FT_OpenEx . You are correctly passing &ftH so that the function can overwrite ftH .

The FT_HANDLE is an input parameter to the other functions. You are incorrectly passing &ftH and should pass just ftH .

FT_Close(&ftH); FT_Close(ftH);

Unfortunately FT_HANDLE is defined in a loosely-typed way:

typedef void* PVOID;
typedef PVOID FT_HANDLE;

Since void** implicitly converts to void* , the compiler cannot help you catch this mistake ¹ . In general opaque handle types should be declared as

typedef struct AlwaysIncompleteType * MY_HANDLE;

and then the pointer and double-pointer types will be appropriately incompatible.

---

¹ Even worse, in C, the reverse conversion from void* to void** is also implicit and you would be allowed to call FT_OpenEx(..., ftH) probably resulting in an immediate access violation (aka segmentation fault) and possibly resulting in unpredictable memory corruption. At least C++ got this right... but void* is still not conducive to strong type checking.