Ticket UUID: | 1823552 | |||
Title: | [info hostname] encoding | |||
Type: | Bug | Version: | obsolete: 8.4.16 | |
Submitter: | dgp | Created on: | 2007-10-31 15:34:18 | |
Subsystem: | 27. Channel Types | Assigned To: | dgp | |
Priority: | 9 Immediate | Severity: | ||
Status: | Closed | Last Modified: | 2007-11-28 03:39:27 | |
Resolution: | Fixed | Closed By: | dgp | |
Closed on: | 2007-11-27 20:39:27 | |||
Description: |
In an application that embeds Tcl, we create data snapshot files, and construct unique filenames to avoid collision when filesystems are shared by several systems running our app, like so: set name foo-[info hostname]-[pid] Some users of our app working on a Chinese Windows system report errors about not being able to find/read these files. After a few rounds of debugging, the problem realtes to their [info hostname] containing Chinese characters. If we revise to set name foo-[encoding convertfrom [info hostname]]-[pid] then the app works again. Looking at the source code fro Tcl_GetHostname() it appears that the translation from system encoding to internal encoding is not done on Windows when the value is retreived from a gethostname() routine. It seems this bug has been undetected for a long time, since it is only very recently that ICANN is permitting domain names to have non-ASCII characters. | |||
User Comments: |
dgp added on 2007-11-28 03:39:27:
Logged In: YES user_id=80530 Originator: YES Issue patched for 8.5.0 as well, though it likely never triggers there. dgp added on 2007-11-28 03:30:56: Logged In: YES user_id=80530 Originator: YES committed for 8.4.17 dgp added on 2007-11-28 03:27:27: File Added - 256332: 1823552.patch Logged In: YES user_id=80530 Originator: YES Here's a patch for 8.4 File Added: 1823552.patch dgp added on 2007-11-16 03:06:53: Logged In: YES user_id=80530 Originator: YES The branch that calls getComputerNameProc() is correct. Since that will presumable always succeed, the HEAD code won't reach the bug. The followup branch that calls gethostname() is the part that is broken. gethostname() empirically returns a string in the [encoding system], but the InitializeHostName() routine assumes the string is in utf-8. On the 8.4 branch, the gethostname() attempt comes before the getComputerNameProc() attempt, so the bug is easier to demo and more important to fix. davygrvy added on 2007-11-16 01:48:30: Logged In: YES user_id=7549 Originator: NO tclWinSock.c:InitializeHostName() on the HEAD looks like it has the correct behavior reading through it. dgp added on 2007-11-16 01:31:15: Logged In: YES user_id=80530 Originator: YES Please note the bug is filed against 8.4.16. The bug is technically present on both branches, but due to other changes, it is practically never encountered on the 8.5 branch. I have a patch in my head to put on the HEAD; just haven't got back to it yet. andreas_kupries added on 2007-11-16 01:24:21: Logged In: YES user_id=75003 Originator: NO When ? I do not remember having worked in this area. davygrvy added on 2007-11-16 01:18:11: Logged In: YES user_id=7549 Originator: NO Andreas, It appears you fixed this. |
Attachments:
- 1823552.patch [download] added by dgp on 2007-11-28 03:27:27. [details]