RE: tmpnam() core dumping

RE: tmpnam() core dumping

[Bill Ahlbrandt]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Understood and agreed.

-----Original Message-----
From:	Andreas Schwab [SMTP:schwab@issan.informatik.uni-dortmund.de]
Sent:	Monday, December 15, 1997 4:51 AM
To:	egcs@cygnus.com
Subject:	Re: tmpnam() core dumping

Bill Ahlbrandt <bahlbr@icdata.com> writes:

|> Yes, using -fwritable-strings fixes the problem.

No, it does not "fix" the problem, it just hides it away.  A program that
must be compiled with -fwritable-strings is simply broken.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org


[-- Attachment #2: bin00000.bin --]
[-- Type: application/vnd.ms-tnef, Size: 2105 bytes --]

Re: tmpnam() core dumping

[Andreas Schwab]

Bill Ahlbrandt <bahlbr@icdata.com> writes:

|> Yes, using -fwritable-strings fixes the problem.

No, it does not "fix" the problem, it just hides it away.  A program that
must be compiled with -fwritable-strings is simply broken.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

RE: tmpnam() core dumping

[Bill Ahlbrandt]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Great!  I get it now.  Thanks for all of the input/help!

-----Original Message-----
From:	Marc Lehmann [SMTP:pcg@goof.com]
Sent:	Friday, December 12, 1997 11:01 AM
To:	egcs@cygnus.com
Subject:	Re: tmpnam() core dumping

On Fri, Dec 12, 1997 at 08:13:46AM -0600, Bill Ahlbrandt wrote:
> I am getting a core dump when I use the tmpnam() function.

RTM, you are calling

tmpnam("xxx"),

and tmpnam tries to overwrite the memory you gave to it (which
is a constant string which is in a readonly section), thus
you get a segmentation fault.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

[-- Attachment #2: bin00000.bin --]
[-- Type: application/vnd.ms-tnef, Size: 2273 bytes --]

Re: tmpnam() core dumping

[Tim Hollebeek]

Bill Ahlbrandt writes ...
> 
> Yes, using -fwritable-strings fixes the problem.
> 
> I wonder why these functions want to modify the string that is passed to them :-)?

Normal behavior.  Otherwise they would have to call malloc() to allocate the
result, or something similar.  E.g. from the IRIX man page:

     tmpnam always generates a file name using the path-prefix defined as
     P_tmpdir in the <stdio.h> header file.  If s is NULL, tmpnam leaves its
     result in an internal static area and returns a pointer to that area.
     The next call to tmpnam will destroy the contents of the area.  If s is
     not NULL, it is assumed to be the address of an array of at least
     L_tmpnam bytes, where L_tmpnam is a constant defined in <stdio.h>; tmpnam
     places its result in that array and returns s.

---------------------------------------------------------------------------
Tim Hollebeek                           | "Everything above is a true
email: tim@wfn-shop.princeton.edu       |  statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim |  false values of true."

Re: tmpnam() core dumping

[Marc Lehmann]

On Fri, Dec 12, 1997 at 08:13:46AM -0600, Bill Ahlbrandt wrote:
> I am getting a core dump when I use the tmpnam() function.

RTM, you are calling

tmpnam("xxx"),

and tmpnam tries to overwrite the memory you gave to it (which
is a constant string which is in a readonly section), thus
you get a segmentation fault.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: tmpnam() core dumping

[Per Bothner]

> I wonder why these functions want to modify the string that is passed to them :-)?

Because that is what the C standard specifies it should do?

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

RE: tmpnam() core dumping

[Bill Ahlbrandt]

Yes, using -fwritable-strings fixes the problem.

I wonder why these functions want to modify the string that is passed to them :-)?

Thanks much... 

-----Original Message-----
From:	Jeffrey A Law [SMTP:law@hurl.cygnus.com]
Sent:	Friday, December 12, 1997 10:05 AM
To:	Bill Ahlbrandt
Cc:	egcs@cygnus.com
Subject:	Re: tmpnam() core dumping 


  In message < 01BD06D5.E1EF50C0@bill.icdata.com >you write:
  > This probably has nothing to do with egcs, but being extremely new this env
  > ironment and compiler, any assistance will be much appreciated.
  > 
  > Note that the tempnam function works just fine.
Does -fwritable-strings fix the problem.

From the GCC manual:
@itemize @bullet
@cindex string constants
@cindex read-only strings
@cindex shared strings
@item
GNU CC normally makes string constants read-only.  If several
identical-looking string constants are used, GNU CC stores only one
copy of the string.

@cindex @code{mktemp}, and constant strings
One consequence is that you cannot call @code{mktemp} with a string
constant argument.  The function @code{mktemp} always alters the
string its argument points to.


This may also apply to tempnam.

jeff

Re: tmpnam() core dumping

[Jeffrey A Law]

  In message < 01BD06D5.E1EF50C0@bill.icdata.com >you write:
  > This probably has nothing to do with egcs, but being extremely new this env
  > ironment and compiler, any assistance will be much appreciated.
  > 
  > Note that the tempnam function works just fine.
Does -fwritable-strings fix the problem.

From the GCC manual:
@itemize @bullet
@cindex string constants
@cindex read-only strings
@cindex shared strings
@item
GNU CC normally makes string constants read-only.  If several
identical-looking string constants are used, GNU CC stores only one
copy of the string.

@cindex @code{mktemp}, and constant strings
One consequence is that you cannot call @code{mktemp} with a string
constant argument.  The function @code{mktemp} always alters the
string its argument points to.


This may also apply to tempnam.

jeff

tmpnam() core dumping

[Bill Ahlbrandt]

I am getting a core dump when I use the tmpnam() function.

I'm running slackware 2.0.29, 

gcc -v gives:

Reading specs from /usr/local/lib/gcc-lib/i486-pc-linux-gnulibc1/egcs-2.90.21/specs
gcc version egcs-2.90.21 971202 (egcs-1.00 release)

This probably has nothing to do with egcs, but being extremely new this environment and compiler, any assistance will be much appreciated.

Note that the tempnam function works just fine.


The following code produces the output that follows:

#include <stdio.h>

int main() {
  char *tempFileName;
  printf("doing tempnam\n");
  tempFileName=tempnam(".","xxx");
  printf("done\n");
  if (tempFileName) {
    printf("I got %s\n",tempFileName);
  } else {
    printf("Got an error\n");
  } /* endif */

  printf("doing tmpnam\n");
  tempFileName=tmpnam("xxx");
  printf("done\n");
  if (tempFileName) {
    printf("I got %s\n",tempFileName);
  } else {
    printf("Got an error\n");
  } /* endif */
  return 0;
}


mail:~/src/bug$ gcc bug.cpp
mail:~/src/bug$ a.out
doing tempnam
done
I got ./xxx30905aaa
doing tmpnam
Segmentation fault (core dumped)
mail:~/src/bug$                                                                                                                                       


Thanks in advance.

Bill Ahlbrandt