Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!cornell!johnhlee
From: johnhlee@CS.Cornell.EDU (John H. Lee)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ANOTHER SAS C BUG
Message-ID: <1991Apr1.050544.13878@cs.cornell.edu>
Date: 1 Apr 91 05:05:44 GMT
References: <1991Mar31.035009.13183@csis.dit.csiro.au>
Sender: news@cs.cornell.edu (USENET news user)
Reply-To: johnhlee@cs.cornell.edu (John H. Lee)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Lines: 40
Nntp-Posting-Host: hermod.cs.cornell.edu

In article <1991Mar31.035009.13183@csis.dit.csiro.au> dave@csis.dit.csiro.au (David Campbell) writes:
>/*  Here is some source which demonstrates a bug in the SAS C
>    compiler */
>
>#include <stdio.h>
>
>char *str="hello\n";
>
>main()
>{
>	char *ptr;
>
>	ptr = str;
>	*ptr = '\001' + *ptr++;
>	printf(str);
>}
>
>/* Should print "iello" through the incrementing of str[0]
>
>   Instead prints "hillo"
[OMD dump deleted]

Is this really a bug?  I believe this is a classic non-portable example as
far as K&R C goes (ANSI C may say otherwise--I not sure.)  The problem is
that we don't know which gets evaluated first:  the lhs or rhs of the
expression.  K&R C leaves this up to the compiler, and it is evaluating
the rhs first so that *ptr on the lhs ends up pointing to str[1].

By the way, your first statement should read:

	char str[]="hello\n";

so that you don't accidently change program constants (but the amount of
memory allocated is the same.)  A rumored VAX side-effect allowed a program
to change the value of the constant 0 this way.

-------------------------------------------------------------------------------
The DiskDoctor threatens the crew!  Next time on AmigaDos: The Next Generation.
	John Lee		Internet: johnhlee@cs.cornell.edu
The above opinions of those of the user, and not of this machine.