Xref: utzoo comp.lang.c:40155 comp.lang.c++:14178
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: array side-effect
Message-ID: <1991Jun18.054347.18854@thunder.mcrcim.mcgill.edu>
Date: 18 Jun 91 05:43:47 GMT
References: <91165.095327PRD3@psuvm.psu.edu>
Organization: McGill Research Centre for Intelligent Machines
Lines: 38

In article <91165.095327PRD3@psuvm.psu.edu>, PRD3@psuvm.psu.edu writes:

> I have found a real stumper.  Partial listing follows:

> int CODE_MATRIX[26][25];         //global
> char INMOD1[50][3];              //global

> int mod_loop=0;                  //local

> mod_loop++;
> INMOD1[mod_loop][0]="9";        //mod_loop is 1

> This last statement changes the value of CODE_MATRIX[26][1] from -9
> to some large random number.

It should provoke a compile-time complaint about assigning a pointer to
an integer ("9" is a pointer[%], but INMOD1[mod_loop][0] is an
integer[$]).

[%] Actually, an array, but in this context it immediately decays to a
    pointer.
[$] I said integer, not int; "char" is one of the integer datatypes.

That aside, CODE_MATRIX[26][1] doesn't exist; the first subscript
ranges only 0..25.  So when you access CODE_MATRIX[26][1] you could get
anything from a coredump to the current time of day in Uganda to (most
likely, in this case) two of the elements of INMOD1 packed together.

> I am using Borland Turbo C++ on a 386Clone running DOS.

Thank you for mentioning this; *nobody* seems to think to say what
machine and OS are in use anymore....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu