linemode browser coredump in HTGetTmpFileName()

I was going to send this just to www-lib-bugs@w3.org, but since someone
else is having linemode browser coredumps, I thought I'd send it
here (www-lib@w3.org) as well.

HTGetTmpFileName() in HTInet.c coredumped on me on Linux; I was running
a modified linemode browser of mine. 

The root cause is a precedence problem in the C code.  I traced this
through purify on Solaris; although it did not dump, there was a clear
memory violation.  This code is in both libwww 5.0a and libwww 5.1a.
(The segment below is taken from 5.0a.)

The only difference here is parentheses for the "?:" conditional
expression.

There is another problem in HTGetTmpFileName(), but I'll get to that
below.

------- HTInet.c -------
***************
*** 576,582 ****
  {
      char * result = NULL;
      char * offset = NULL;
!     if (!(result = (char *) HT_MALLOC(dir ? strlen(dir) : 0 +HT_MAX_TMPNAM+2)))
  	HT_OUTOFMEM("HTGetTmpFileName");
      if (dir && *dir) {
  	strcpy(result, dir);
--- 576,582 ----
  {
      char * result = NULL;
      char * offset = NULL;
!     if (!(result = (char *) HT_MALLOC((dir ? strlen(dir) : 0) +HT_MAX_TMPNAM+2)))
  	HT_OUTOFMEM("HTGetTmpFileName");
      if (dir && *dir) {
  	strcpy(result, dir);

As the first second problem...

HTGetTmpFileName("/tmp") generates a name like "/tmp/tmp/00273baa" on
Linux.  It did some similar thing on Solaris.  When the result is used
to actually create the file, the "/tmp/tmp" directory doesn't exist,
causing the program to crash.

It is not clear to me what the solution is.  It is using tmpnam() or
tmpnam_r(), which don't seem to handle a prefix.  tempnam() might be
more appropriate, but that is what the HT_MALLOC() call is for.

Then again, what does HTGetTmpFileName() do that tempnam() doesn't?

--Rick Kwan
  rick.kwan@NetPhonic.COM

Received on Friday, 28 March 1997 21:00:16 UTC