Problem with serial port and external DLL

[User002]

No, there is no VI.

I don't get, what

strcpy(&port,(LPCTSTR)m_1_connect_turntable);

causes. m_1_connect_turntable is _T("").

[rolfk]

It's a global variable so one of the calls to UpdateData() most likely copies the number from the UI into this variable.

[User002 · Accepted solution]

I found the solution (some weeks ago):

When the turntable is connected to Port COM6, I don't have to pass an integer of "6" but a "54" to the function (the corresponding ACSII character of a "6"). Everything works fine now, thank you all for your help.

Regards

Florian

[rolfk]

well I see, it sort of could have been infered from the source, but without the context where it was read from the control and seeing that that control is in fact a string and not an integer, it's pretty hidden.

BTW. I took a look at the source code snipped you showed and it is BAAAD!

---

@User002 wrote:

Yes, I've got the cpp source file of the test application.

m_1_connect_turntable = _T("");

//...

void CDllTestExeDlg::OnBTNconnectturntable() 
{	
	UpdateData(true);
	m_h_connect_turntable=0;
 	m_ret_connect_turntabele =0; 
	UpdateData(false);
	UpdateData(true);
	char port ;
	strcpy(&port,(LPCTSTR)m_1_connect_turntable);
 	m_ret_connect_turntabele = ConnectTurntable(   &m_h_connect_turntable,port );
	UpdateData(false);	
}

---

The red part is potentially causing a memory corruption. There is a one byte variable "port" on the stack which is then copied the string contained in m_1_connect_turntable. This will copy at least the entered number character PLUS one null termination character into a variable that can only really hold one byte. It is likely going ok since the stack is usually aligned to 4 byte bounderies so that that additional null byte is written into unused memory but it is definitely bad. And unless they do some parameter verification when copying the control contents into m_1_connect_turntable, things might get very interesting if the user wants to enter COM port numer 2345. Then the stack truely would get corrupted and the software would crash badly sooner or later.

All in all, the fact that the port number is supposed to be the ASCII chracter for the actual number and this rather stupid error doesn't give me a lot of confidence for the rest of the software, both inside the device firmware as in their PC host software.

[User002]

Yes, you are right. I just tried to enter a four digits number in the software and it crashed :-).

[rolfk]

And it only really works for COM ports up to COM9. Probably not a big problem in most situations but definitely a totally unnecessary limitation. And COM10 and higher is not impossible to get when you have added several serial devices to a system.