Tcl Source Code

View Ticket
Login
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: