Order of declaration of variables changes the output?

[Yuval K]

I've encountered something odd...

A friend of mine just started C and had this problem.

Here's very simple (bugged) program which still works correctly.
#include <stdio.h>



int main()

{

char b,radius,area,a;



printf("Ente 3 numbers:\n");

scanf("%d",&area);

scanf("%d",&radius);

scanf("%d",&b);

printf("%c%c%c\n",radius,area,b);

return 0;

}


Of course there's problem with conversion from int to char etc, but it
still reads and prints the symbols that you've entered.

On the other hand if you move 'b' to the end of declaration it doesn't
print the 3 letters as it should.

int main()
{
char radius,area,a, b;
printf("Ente 3 numbers:\n");
scanf("%d",&area);
scanf("%d",&radius);
scanf("%d",&b);
printf("%c%c%c\n",radius,area,b);
return 0;
}

I've used gcc compiler.

Could someone explain me the reason why the order of declaration
changes the output?

Thanks.

 

[Willem]

Yuval K wrote:
) I've encountered something odd...
)
) A friend of mine just started C and had this problem.
)
) Here's very simple (bugged) program which still works correctly.
<snip>
) char radius,area,a, b;
) printf("Ente 3 numbers:\n");
) scanf("%d",&area);
) scanf("%d",&radius);
) scanf("%d",&b);
) printf("%c%c%c\n",radius,area,b);
<snip>
) Could someone explain me the reason why the order of declaration
) changes the output?

Thats because it's undefined behaviour. (scanf expects pointers to int.)
Anything can happen, *including* everything working as expected.

It could be that when you compile it tomorrow, the results are different.

The scanf wants to write sizeof(int) bytes of data into a place where
there's only enough room for 1 byte. So the other bytes are written
somewhere else, causing all kinds of havoc. Possibly. Or not.
That's undefined behaviour for you.

You shouldn't worry about it, just fix the bug (change 'char' to 'int').


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Charlton Wilbur]

YK> Could someone explain me the reason why the order of declaration
YK> changes the output?

You tell scanf that the next arguments are going to be pointer-to-int
(that's what %d means), but you pass in pointer-to-char. That's
undefined behavior, and once you do that, all bets are off.

Charlton

 

[Seebs]

I've encountered something odd...

No, just something you're not used to yet.

char b,radius,area,a;
scanf("%d",&area);

"char" is usually smaller than "int".

Formally speaking, "this is undefined behavior". Anything can happen.

What is PROBABLY happening is like this.

Imagine that there's a hunk of memory, holding these objects:

[ ] b
[ ] radius
[ ] area
[ ] a

You read in an integer, to &area. You enter "3". What you have now is:

[ ] b
[ 0 ] radius
[ 3 ] area
[ ] a

Where'd the 0 come from? Well, "%d" expects a pointer to int. It has
no idea what you gave it a pointer to, except that you *told* it it would
be a pointer to int. So it dutifully stores an int, which takes up more
than one char in memory (on your system, and indeed on most systems).

scanf("%d",&radius);

Okay. You enter 5:

[ 0 ] b
[ 5 ] radius
[ 3 ] area
[ ] a

scanf("%d",&b);

And you enter 6:

0 ?????
[ 6 ] b
[ 5 ] radius
[ 3 ] area
[ ] a

printf("%c%c%c\n",radius,area,b);

BTW, this obviously didn't do what you said it did, because this would
print the raw characters with those values (e.g., on an ASCII system,
if you entered a 101 for one of these, you'd get 'a' for it).

Of course there's problem with conversion from int to char etc, but it
still reads and prints the symbols that you've entered.

Well, that is indeed the point.

On the other hand if you move 'b' to the end of declaration it doesn't
print the 3 letters as it should.

Anything it does is "as it should". You invoked undefined behavior.

Could someone explain me the reason why the order of declaration
changes the output?

The automatic objects are allocated in an unspecified order, but quite
often in an order reflecting the order you declared them in. Because there's
often a relationship there, it is likely to turn out that overwriting
the bounds of one of these objects will have effects which differ depending
on the order in which the objects were declared, although it's hardly
guaranteed.

-s