Tcl Source Code

It seems that on Unix, that value of
tcl_platform(user) is simply copied over
from env(USER) or env(LOGNAME).
There doesn't seem to be any attempt
to discover and report the actual
uid under which the process is running.

On Windows, the value is taken first
from env(USERNAME), and a call
to GetUserName() takes place only
if env(USERNAME) is not set.

This is a bit troubling.  Tcl already provides
access to the environment variables
via the env array, so there's really
nothing new provided.  However, because
the value is placed in tcl_platform(user)
it gains the color of authority as a value 
provded by Tcl iteself, distinguished
from the env variable values, which any
programmer knows can be set by the
end user.

Anyone programmer trusting tcl_platform(user)
to be truthful is acting on misplaced faith.
The existence of tcl_platform(user) encourages
such inappropriate trust.

Logged In: YES 
user_id=79902
Originator: NO

Fixed in HEAD.

Logged In: YES 
user_id=240

Hi,

The fact that it is going after USER and LOGNAME env
variables is also problematic in environments where those
are not set.  I just spent a couple of hours chasing down a
bug in tcllib's mime smtp package which turns out to be
related to the fact that under Apache, those variables are
not set, and so tcl_platform(user) is empty.  I think that
looking at getpwuid is far better than leaving this empty.

Thanks,
Dave

Logged In: YES 
user_id=79902

Problem: Code is not thread-safe and probably not possible
to make thread-safe (not all platforms have getpwuid_r);
perhaps a mutex lock would help?

File Deleted - 101021: 



File Added - 101026: user.diff

Logged In: YES 
user_id=79902

Oops.  Inverted test sense and forgot to convert encodings.
 Try this fixed version.

File Added - 101021: user.diff

Logged In: YES 
user_id=79902

Here's a simple basic patch.  Any reason why this isn't
sufficient (possibly after hacking around with autoconf and
moving the #includes to tclInt.h, of course.)

Logged In: YES 
user_id=80530


not really, but it is part of a larger
observation that the contents of the
tcl_platform are losing their coherence.

the name "tcl_platform" suggests
information about the platform on
which the program is running, and
most elements do that: platform,
machine, os, osVersion, byteOrder,
and wordSize.

tcl_platform has added (sometimes) the elements
threaded and/or debug, which really tell
you about the variant of the Tcl library
itself, not something about the platform.
Data that would be better in something like
tcl::config or [package about Tcl].

Finally, we have tcl_platform(user), which
turns out to just be an alternative name for
the variable env(USER).  It has nothing to
do with the platform, it duplicates something
we already had, and because of that duplication,
suggests the possibility of greater authority that
isn't really there.  All (potential) confusion, and
nearly zero utility.

*If* tcl_platform(user) were connected to the
getuid() call, at least then I could defend it as
a poor interface to useful information.  Looks like
a complete mistake as is.

Logged In: YES 
user_id=79902

Hmm.  Is this a call to use getpwuid(getuid()) on UNIX? 
(Which probably needs thread-protection too.  I'd be
startled if getpwuid was reentrant normally...)