Tcl Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: ed5be77734b7e0dd01d2fc6f9bcc2b260c31cc8d
Title: win: "comx:" not recognized as serial port
Type: Bug Version: 8.6.3
Submitter: oehhar Created on: 2014-12-04 12:43:02
Subsystem: 24. Channel Commands Assigned To: jan.nijtmans
Priority: 5 Medium Severity: Important
Status: Closed Last Modified: 2020-12-10 13:44:24
Resolution: Fixed Closed By: oehhar
    Closed on: 2020-12-10 13:44:24
Description:

Serial port names are not detected as such if postpended by ":".

E.g.

% open com1: r+
couldn't open "com1:": no such file or directory
% open com1 r+
file2672fb0

This was present in 8.6.2 and was normally fixed in TCL 8.6.3. Something went wrong, fix not included, whatever.

Harald

User Comments: oehhar added on 2020-12-10 13:40:53:

We have two corrections:

1)

3102 3102 MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS, str, -1, nativePathPtr,

  1. - len + 1);
  2. + len + 2);

2)

  1. + nativePathPtr[len] = 0;

I first tested correction (2) which did the job.

Correction 2) feels also ok. The buffer has len+6 size.

Thank you, Harald


jan.nijtmans added on 2020-12-10 13:39:29:

Thanks for testing! Yes, it was a general issue in the native path machinery. A situation in which a WCHR string was not NULL-terminated, that's what made this so difficult to track down.

Anyway, it will be finally (after 6 years!) fixed in Tcl 8.6.11. Yeah!


oehhar added on 2020-12-10 13:10:52:

Great! For me, that fixes the issue.

I have build against tk8.6.10 release with MS-VC6 on Windows 32 bit.

The issue you found looks like a more general issue in the native path machinery.

Thank you, great, Harald


jan.nijtmans added on 2020-12-10 12:26:02:

New assumption: In tclWinFile.c, line 3087, a comment sais: "For a reserved device, strip a possible postfix ':'". But in reality, the path given to MultiByteToWideChar() is not null-terminated in this case. That looks, wrong, and might be the cause for this problem.

I'm not on a Windows machine now, I will test this soon, when I can.

If this assumption is true, the fix is here: [cba5e7728d8a6b45]


oehhar added on 2020-12-09 16:52:04:

A sister ticket is opened in Tk, as this only shows up in WISH:

https://core.tcl-lang.org/tk/info/89781ed82e349f97


oehhar added on 2020-11-17 16:25:40:

Issue still present in TCL 8.6.10


tomkiti added on 2018-10-27 09:11:51:
Any progress on this? It's still not working in 8.6.8. This breaks our code when upgrading from 8.5 to 8.6.

oehhar added on 2015-06-24 07:11:05:

Discussion with Jan Nijtmans on ETCL:

  • It appears only in the wish console, not when the script is started like 'wish.exe -f script.tcl'
  • Jan supposes, tat the reason lies in the stdin/stdout magic of the wish console which, by accident, does something with "comx:".


oehhar added on 2015-05-06 14:57:41:

I have reverified with tcl8.6.4:

wish 8.6.4:

% set h [open com1: r+]
couldn't open "com1:": no such file or directory
% set h [open com1 r+]
file677a6e8

and with tclsh8.6.4:

% set h [open com1: r+]
file63c988
% close $h
% set h [open com1 r+]
file63d388

So the bug is still present when wish is used and not in tclsh. Harald


dgp added on 2015-05-01 14:38:44:
status?

jan.nijtmans added on 2014-12-05 15:49:09:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-05 15:48:26:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-05 15:47:00:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-04 14:18:15:

Starting with [80d513f9cb4b2e0350b1e822041322cb4330e90f|80d513f9cb4b2e03], unsafe characters (like ':') in filenames are replaced with Unicode character\uf0?? in the native form. This makes those files work transparantly, no matter if they are accessed using win32 tclsh or cygwin tclsh. For more information, see: https://cygwin.com/cygwin-ug-net/using-specialnames.html. This fully explains the appearance of the "dingbat". However, when the filename references a serial port, this conversion should not be done, that's what fixed in 8.6.3.

Why this still doesn't work in wish is a big question for me.


oehhar added on 2014-12-04 13:39:27:

dburns on the chat: 8.6.2 windows " open com1: w" creates a file with name "com1[]" where [] is a dingbat

The file may not be listed using "glob com1*".

Win XP with a physical com port

This is 8.6.2, so between the revevant patches...


oehhar added on 2014-12-04 13:15:57:

I have made some additional tests sheding more light ;-)

From release 8.6.3:

  • tcl86t.exe: does not show the issue
  • wish86t.exe: has the issue

The same is verified with the bugfix checkin was [f27ce7a1a5] and Tk8.6.3.

So, the issue only arises for wish and not for tclsh.