RE: tmpnam() core dumping

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

[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: [EGCS] RE: tmpnam() core dumping

[Marc Lehmann]

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

because it's documented that way... many functions like "working space",
which makes them thread safe.

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

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

[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