From: br5an AT aol DOT com (Br5an)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Is this a bug ??? or feature ??
Date: 14 Oct 1997 22:33:20 GMT
Lines: 41
Message-ID: <19971014223300.SAA13822@ladder01.news.aol.com>
NNTP-Posting-Host: ladder01.news.aol.com
Organization: AOL http://www.aol.com
References: <19971013092045 DOT 160 DOT rocketmail AT send1 DOT rocketmail DOT com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Guan Foo Wah wrote:
snip:
>This is the output compiled on the DJGPP compiler (using BNU281B.ZIP)

>Address : 155b 155b 155b
>Value before modifying : one one one
>Value after modifying  : fne fne fne

>and this is the output compiled on the TURBO C v3.0

>Address : 00BC 00C0 00D7
>Value before modifying : one one one
>Value after modifying  : fne one one

>From the program output compiled on the DJGPP compiler, it seems that
>num[0], num[1] and id[2] share the same location memory. Why is this
>so ??
>When line 4 in the code which is "one" is replaced with "one ", the
>output
>will change to the one below.

>Address : 155f 155b 155b
>Value before modifying : one  one one
>Value after modifying  : fne  one one

>This time, num[1], and id[2] share the same memory location.
>Can anyone please tell me how to make those three variables not to
>share
>the same memory location ?? This is important in my project which I am
>currently working on.

Guan Foo Wah,
     I can't be sure without experimenting some but it sounds like the compiler
 is optimizing duplicate strings. You will find this is an option with Turbo
 C++ 3.0  (Options / Compiler / Code Generation).  For now all I can suggest is
 to declare your arrays, and then to set there contents later in the code
 (inside main?) and see if that helps. Hopefully someone else may come through
 with how to disable the optimization (if that's the case) or with another
 idea.
                        Sincerely,
                                  Br5an AT aol DOT com