[5046] in SIPB bug reports
sun4m_53: detex
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Mon Nov 21 14:40:58 1994
Date: Mon, 21 Nov 1994 14:40:31 +0500
From: "Mark W. Eichin" <eichin@MIT.EDU>
To: bert@MIT.EDU
Cc: bug-sipb@MIT.EDU
In-Reply-To: "Albert Dvornik"'s message of Sat, 19 Nov 1994 06:25:39 EST <9411191125.AA07467@infocalypse.MIT.EDU>
>> finally realized what the problem was: for some reason you *can't*
>> modify static strings if you compile {with,on} {/mit/gnu/bin/gcc,Sun}.
That's permitted by ANSI (though it's not strictly required.) ANSI
specifically allows common strings to be shared:
3.1.4 ...
Identical string literals of either form [wchar_t or char --me] need
not be distinct. If the program attempts to modify a string literal of
either form, the behaviour is undefined.
GCC lets you get around code that assumes that strings are writable
with -fwritable-strings, but it's better to fix the code...
_Mark_
ps. from gcc.texi:
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.
Another consequence is that @code{sscanf} does not work on some systems
when passed a string constant as its format control string or input.
This is because @code{sscanf} incorrectly tries to write into the string
constant. Likewise @code{fscanf} and @code{scanf}.
The best solution to these problems is to change the program to use
@code{char}-array variables with initialization strings for these
purposes instead of string constants. But if this is not possible,
you can use the @samp{-fwritable-strings} flag, which directs GNU CC
to handle string constants the same way most C compilers do.
@samp{-traditional} also has this effect, among others.
