Path: utzoo!mnetor!uunet!husc6!hao!noao!mcdsun!fnf
From: fnf@mcdsun.UUCP (Fred Fish)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <633@mcdsun.UUCP>
Date: 5 Jan 88 21:22:58 GMT
References: <4668@pyr.gatech.EDU> <2046@haddock.ISC.COM> <400@uniq.UUCP> <2124@haddock.ISC.COM>
Reply-To: fnf@mcdsun.UUCP (Fred Fish)
Organization: Motorola Microcomputer Division
Lines: 38

In article <2124@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <400@uniq.UUCP> dfm@uniq.UUCP (Meyer) writes:
>>... there was an implementation where string constants were put in read-only
>>(text??) memory, and changing them produced [some fault].  ...
>>Since then, I have never assumed that I could write into a literal.
>
>I've always considered it atrocious to do so, but the fact is that K&R did
>explicitly allow it (why!?), and so any pre-ANSI implementation that put
>string literals into read-only memory would have to be judged "broken".
>
>The new rule is a Quiet Change, but it doesn't bother me a bit.

I have a feeling this is going to break more code than just the obvious 
stuff, including something deep in the bowels of stdio.  Consider the
following:

/*
 *	This program causes a segmentation violation in ungetc when
 *	compiled under GNU C 1.16 and run on a Sun-3/50 under SunOS 3.2.
 *	This is because GNU C is a mostly ANSI conforming compiler
 *	and places strings in a readonly section of memory, but
 *	sscanf apparently believes that it can write to the memory
 *	pointed to by it's first argument.
 *
 *	I believe this to be a legitimate bug in sscanf that will
 *	eventually need to be fixed anyway to achieve ANSI compatibility.
 *
 */

main ()
{
    char buffer[64];

    sscanf (" this is", "%s", buffer);
}
-- 
# Fred Fish    hao!noao!mcdsun!fnf    (602) 438-3614
# Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282  USA