sir,i have got 2 bedrock doubts

[PRADEEP]

sir,
I request you to give the explanation for the below mentioned
problems:
1)

#include<conio.h>
#include<stdio.h>
void main()
{
int in;
printf("Enter a number:");
scanf("%d\n",in);
printf("ANSWER\n");
printf("%d\n",in);

}

output

Enter a number:6
-----------------------------------------------------
ANSWER
6

NOTE:the dotted lines after the prompt "enter a number" forces the
programmer to enter sth (a character or a string (with or without
space)or a number)
but doesn't proceed to next statement unless sth is entered as
mentioned above.
Also,note that dotted lines do not appear as shown in the above sample
o/p.This is for
putting forward my doubt in trenchant vein.

2)
#include<conio.h>
#include<stdio.h>
void main()
{
int i=9;
printf("%d %d %d %d",i++,++i,i--,--i);
getch();

}

output

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9.please give me an explanation for this. I need an
explanation for the above problem too.

Thanking you.

your's respectfully.

 

[Joe Pfeiffer]

sir,
I request you to give the explanation for the below mentioned
problems:
1)

#include<conio.h>
#include<stdio.h>
void main()
{
int in;
printf("Enter a number:");
scanf("%d\n",in);
printf("ANSWER\n");
printf("%d\n",in);

}

output

Enter a number:6
-----------------------------------------------------
ANSWER
6

NOTE:the dotted lines after the prompt "enter a number" forces the
programmer to enter sth (a character or a string (with or without

Does 'sth' mean 'something'?

space)or a number)
but doesn't proceed to next statement unless sth is entered as
mentioned above.
Also,note that dotted lines do not appear as shown in the above sample
o/p.This is for
putting forward my doubt in trenchant vein.

What is your question? Note that I'm really surprised this compiled
(let alone printed the number entered by the user), since your variable
'in' needs to be a pointer and isn't.

2)
#include<conio.h>
#include<stdio.h>
void main()
{
int i=9;
printf("%d %d %d %d",i++,++i,i--,--i);
getch();

}

output

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9.please give me an explanation for this. I need an
explanation for the above problem too.

The parameters are evaluated and pushed on the stack right-to-left, so
the result is exactly what should be expected.

Note -- I don't think this behavior is actually guaranteed (so another
implementation could give the results you were expecting). Even if it
is, coding like that isn't something to which you want to subject some
later reader of your code.

An unrelated additional thing: don't use void main()

First, main should be of type int. Many textbooks get this wrong and
say to use void as you did; you should cast a skeptical eye on all code
examples in these books. The standard says it's an int.

Second, the parameters should be either (void) or (int argc, char *argv[])
In general, empty parameter lists should never appear; a function with
no parameters should be declared with a (void) parameter list. The same
books that mess up the first point also tend to mess up the second.

 

[John Gordon]

scanf("%d\n",in);

This scanf call has two problems:

1. You're passing 'in' to scanf directly, rather than the *address* of in,
so scanf can't assign the scanned value. If your sample program really
did print "6" as you say below, it was purely an accident.

2. You're including "\n" as part of the input pattern itself, which
causes the odd behavior. Take the "\n" out of the input pattern.

int i=9;
printf("%d %d %d %d",i++,++i,i--,--i);

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9.please give me an explanation for this. I need an
explanation for the above problem too.

Even though the function arguments are written left-to-right, they aren't
necessarily evaluated in that order.

 

[Ben Bacarisse]

sir,
I request you to give the explanation for the below mentioned
problems:
1)

#include<conio.h>
#include<stdio.h>
void main()
{
int in;
printf("Enter a number:");
scanf("%d\n",in);
printf("ANSWER\n");
printf("%d\n",in);

}

output

Enter a number:6
-----------------------------------------------------
ANSWER
6

NOTE:the dotted lines after the prompt "enter a number" forces the
programmer to enter sth (a character or a string (with or without
space)or a number)
but doesn't proceed to next statement unless sth is entered as
mentioned above.
Also,note that dotted lines do not appear as shown in the above sample
o/p.This is for
putting forward my doubt in trenchant vein.

I can't see a question here. There are some issues with you code but
they may not relate to why you are posting. Here they are none the
less...

Don't include conio.h. It's non-standard and you don't use anything
from it. It just needlessly complicates the code.

main should be defined

int main(void)

i.e. it returns an int (it always has done) and, since the standard of
1990 it has been the norm to write (void) when a function takes no
arguments.

Since main returns an int, you should include return 0; at the end.

The %d format for scanf expects a pointer and you pass an int. This is
so serious an error that I imagine the problem is that you typed the
code in and forgot the &. It's much better to cut-and-paste (or
otherwise include directly) your programs so that you don't add errors
that are not there.

2)
#include<conio.h>
#include<stdio.h>
void main()
{
int i=9;
printf("%d %d %d %d",i++,++i,i--,--i);
getch();

}

output

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9.please give me an explanation for this. I need an
explanation for the above problem too.

This is a FAQ but the C FAQ site (c-faq.com) seems to be down. The code
is undefined because it violates a rule in the language standard that
says that an object can only be modified once between so-called sequence
points. The purpose of this rule is to permit compilers some freedom
about when side effects (like the increments and decrements in your
code) actually occur. Formally, any output at all (or none) is possible
since the code has no defined meaning.

 

[Leonard K.]

sir,
I request

No need to be so formal. There are plenty of full-on fucking retards on
usenet that will help you with your homework assignment or job you got
in-sourced with.

 

[James Waldby]

2)
#include<conio.h>
#include<stdio.h>
void main()
{
int i=9;
printf("%d %d %d %d",i++,++i,i--,--i); getch();>>
}

output

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9. [...]

The parameters are evaluated and pushed on the stack right-to-left, so
the result is exactly what should be expected.

Note -- I don't think this behavior is actually guaranteed (so another
implementation could give the results you were expecting). Even if it
is, coding like that isn't something to which you want to subject some
later reader of your code.

Right, 6.5.2.2p10 (in N1256 draft) says, "The order of evaluation of the
function designator, the actual arguments, and subexpressions within the
actual arguments is unspecified, but there is a sequence point before
the actual call." 6.5.2.2p12 says, "EXAMPLE In the function call
(*pf[f1()]) (f2(), f3() + f4()) the functions f1, f2, f3, and f4 may
be called in any order. All side effects have to be completed before
the function pointed to by pf[f1()] is called."

 

[James Kuyper]

sir,
I request you to give the explanation for the below mentioned
problems:

The problems you refer to have already been addressed by others, so I'll
just comment on the form of your request. You've written your message as
if it were being sent to a single person. You're posting it in a
location where hundreds, and possibly thousands, of people world-wide
will see it. "dear sirs" would be more appropriate - but it's more
conventional, in such situations, to simply leave out the salutation
entirely.

Also, keep in mind that many of the people who will see it may not be
correctly addressed as 'sir' - 'madam' might be more appropriate to some
of them (though admittedly not very many in this newsgroup). Was the
exclusion of those others intentional? If so, I recommend re-thinking
that idea.

 

[Ben Bacarisse]

2)
#include<conio.h>
#include<stdio.h>
void main()
{
int i=9;
printf("%d %d %d %d",i++,++i,i--,--i); getch();>>
}

output

9 9 8 8

I want to know how came this o/p ,when one would obviously expect the
o/p to be 9 11 11 9. [...]

The parameters are evaluated and pushed on the stack right-to-left, so
the result is exactly what should be expected.

Note -- I don't think this behavior is actually guaranteed (so another
implementation could give the results you were expecting). Even if it
is, coding like that isn't something to which you want to subject some
later reader of your code.

Right, 6.5.2.2p10 (in N1256 draft) says, "The order of evaluation of the
function designator, the actual arguments, and subexpressions within the
actual arguments is unspecified, but there is a sequence point before
the actual call." 6.5.2.2p12 says, "EXAMPLE In the function call
(*pf[f1()]) (f2(), f3() + f4()) the functions f1, f2, f3, and f4 may
be called in any order. All side effects have to be completed before
the function pointed to by pf[f1()] is called."

Reading only this, one might think that all the possible outcomes could
be enumerated simply by considering all the different ordering for
evaluating the function's arguments, or that one need only consider the
order in which the side effects happen, but it's worse than that: 6.5 p2
makes the behaviour undefined.

It's possible that this UB will be exploited in the future in more and
more unpredictable ways. As memory hardware becomes more and more
sophisticated, who's to say what will happen when multiple un-sequenced
updates are scheduled?