Tcl Source Code

$ uname -a
Linux redhat 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001
i686 unknown
$ /usr/local/bin/g++ --version
2.95.3
vendor - redhat 7.1

When I compile

/usr/local/bin/g++ -g -o myexecutable main.o -L.
-L/usr/X11R6/lib -L/usr/local/lib -ltcl8.3 -ltk8.3
-lX11 -lXext

I get the following warning
/usr/local/lib/libtcl8.3.a(tclUnixPipe.o): In function
`TclpCreateTempFile':
tclUnixPipe.o(.text+0xb4): the use of `tmpnam' is
dangerous, better use `mkstemp'

Logged In: YES 
user_id=32170

Patch passes test-suite on linux, windows, so labelled as 
fixed.  Am happy to debate/modify precise implementation as 
desired.

File Added - 10332: tclload.patch

Logged In: YES 
user_id=32170

I've attached a patch to fix this and enable the 'test' 
filesystem to do what it is supposed to.

Logged In: YES 
user_id=32170

How about:

Tcl_Obj* 
TclpTempFileName()
{
    char fileName[L_tmpnam + 9];
    Tcl_Obj *result = NULL;
    int fd;

    /*
     * We should also check against making more than
     * TMP_MAX of these.
     */

    strcpy(fileName, P_tmpdir);/* INTL: Native. */
    if (fileName[strlen(fileName) - 1] != '/') {
strcat(fileName, "/");/* INTL: Native. */
    }
    strcat(fileName, "tclXXXXXX");
    fd = mkstemp(fileName);/* INTL: Native. */
    if (fd == -1) {
return NULL;
    }
    fcntl(fd, F_SETFD, FD_CLOEXEC);
    unlink(fileName);/* INTL: Native. */

    result = TclpNativeToNormalized((ClientData) fileName);
    close (fd);
    return result;
}

Logged In: YES 
user_id=32170

It does look as if mkstemp() could do the job, since it is 
documented to do what you want.

I'll take a look...

Logged In: YES 
user_id=79902

Apparently mkstemp() modifies its string 'template' argument
to be the file that it has opened for you, though the
documentation (on Solaris) is not particularly clear on this
point (but experiment confirms it.) Maybe it is possible to
bodge a fix like that? (The permissions on the temporary
file seem sensible too, and /tmp is usually configured to be
difficult for someone to compromise *too* much.)

Logged In: YES 
user_id=32170

This cannot be fixed until we can dlload from memory or the 
contents of a channel.  This bug is postponed until such a 
time.

Logged In: YES 
user_id=32170

Can't fix this until we can dlload from memory or from 
the contents of a channel (instead of from a named 
file). 

Not sure what state that means we should move this to.

Logged In: YES 
user_id=75003

Jeff tells me that Vince Darley knows how to actually fix 
this and that he will do so. Changing maintainer.

Logged In: YES 
user_id=80530

Hmmm... looks like a duplicate of 442636, but
that report is closed, and the problem is still
there in the HEAD.

Anyhow, the problem is in unix/tclUnixPipe.c,
part of the ChannelTypes category, so I'm passing
the buck.