Strange Behavior?

Shiping Zhang ping at cubmol.bio.columbia.edu
Fri May 10 23:55:52 AEST 1991


In article <1991May9.161425.17079 at mccc.edu> pjh at mccc.edu (Pete Holsberg) writes:
<In article <1991May8.204009.1694 at cubmol.bio.columbia.edu> ping at cubmol.bio.columbia.edu (Shiping Zhang) writes:
<=In article <1991May8.020720.20170 at mccc.edu> pjh at mccc.edu (Peter J. Holsberg) writes:
<=>Here is an extract from a program a student wrote.  Note that he has
<=>declared "input" incorrectly.  The strange behavior is that, when choice
<=>"1" is made, the print function outputs all but the first line that was
<=>entered.  Can anyone explain that in terms of what scanf() is doing to
<=>memory near "input"?  (This is on a 386, if endianism matters.)
<=[...]
<=>   char sentence [MAX][SIZE];   /* an array of strings */
<=>   char *point[MAX];            /* an array of pointers to char */
<=>   char *orginal[MAX];          /* an array holding the orginal sequence */
<=>   char input;	/* SHOULD HAVE BEEN int input!!!  */
<= 
<=[...]
<= 
<=>	printf("Make a choice: ");
<=>	scanf ("%d" , &input);      /* value converted to decimal integer

<=I think it results from declaring input as char and using it as int
<=in scanf(). When scanf() writes 1 into the location of input, it puts
<=into 0's those bits that belong to the first byte(s) of sentence[0],
<=terminating sentence[0] at its first byte.  I could be wrong, though.
 
<I'm sure you're right.  But what I really want to know is why the
<compiler assigns memory that way.  It would seem to me that it would
<assign memory "downward," so that the attempt to write a 4 byte value
<into a 1 byte location would result in the "corruption" of the 3 cells
<*following* the one allocated to "input."
 
The memory space is allocated for those variables as a stack. The space
for a later declared varible is put on the top of the stack with a smaller
address. According to the order in which the variables are declared in this
case, the space for input is on the top. After all I might be wrong in my
previous post. In this case, it should be the pointer original[0] that is
corrupted, making it point to an invalid location. You can actually check the
location of those variables by printing out their addresses as in the following
code:

printf("sentence[0] %d, original[0] %d, input %d\n",
    (int) sentence, (int) original, (int) &input);

-ping




More information about the Comp.lang.c mailing list