Tcl Source Code

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

E.g.
<verbatim>
% open com1: r+
couldn't open "com1:": no such file or directory
% open com1 r+
file2672fb0
</verbatim>

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

Harald

We have two corrections:

1)

3102   3102       MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS, str, -1, nativePathPtr,
  3103         -	    len + 1);
         3103  +	    len + 2);

2)

         3104  +    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

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!

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

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]

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

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

Issue still present in TCL 8.6.10

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.

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:".

I have reverified with tcl8.6.4:

wish 8.6.4:
<verbatim>
% set h [open com1: r+]
couldn't open "com1:": no such file or directory
% set h [open com1 r+]
file677a6e8
</verbatim>

and with tclsh8.6.4:
<verbatim>
% set h [open com1: r+]
file63c988
% close $h
% set h [open com1 r+]
file63d388
</verbatim>

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

status?

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.

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.

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.

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.

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...

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.