sir,i have got 2 bedrock queries

sir,
I request you to give the explanation for the below mentioned
problems:
1)
#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.

2)

#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 need an explanation for
the above problem
too.

Thanking you.

your's respectfully.

PRADEEP

PRADEEP wrote:

> sir,
> I request you to give the explanation for the below mentioned
> problems:
> 1)
> #include<conio.h>

Non-standard header.

Fix: Just get rid of it, unless you need it for something important.

> #include<stdio.h>
> void main()

Undefined behaviour. In C, the return type of main() is int. If you choose
some other return type, you are no longer programming in C.

Fix: int main(void)

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

Since the evaluation order of function arguments is unspecified, this could
print any of many things. Since the behaviour of the program is undefined
anyway, the possible range of outputs is quite astonishing.

Fix: decide what you want to print, and print it.

> getch();

Non-standard function.

Fix: just remove it, unless it does something terribly important.

> }
>
> 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.

Is that really so obvious? Here is a third possibility:

8, 8, 8, 8.

Indeed, it is the behaviour I would have expected, had I been silly enough
to expect a given result, and were it not for the void main() making the
whole point moot.

> #include<conio.h>
> #include<stdio.h>
> void main()

You really are going to have to stop doing that.

> {
> int in;
> printf("Enter a number:");
> scanf("%d\n",in);

Pass the address of the int, not the int itself. Check the return value. Do
not proceed until you are happy with it.

<snip>

--
Richard Heathfield :
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Richard Heathfield

In 'comp.lang.c', (PRADEEP) wrote:

> sir,
> I request you to give the explanation for the below mentioned
> problems:
> 1)
> #include<conio.h>

Non standard header. You probably don't need it.

> #include<stdio.h>
> void main()

Where did you learn that? main() returns int from the origin of times...

int main()

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

NEVER use unary operators in parameters. The result is not defined.

> getch();

get rid of that. Use getchar() if you inist...
and add:

return 0;

> }
>
> output
>
> 9 9 8 8
>
> I want to know how came this o/p ,when one would obviously expect the
> o/p

Unpredicable things are not-obvious by-definition.

> to be 9 11 11 9.please give me an explanation for this.

There is no way to explain an undefined behaviour. Just don't do that. Never.

> 2)
>
> #include<conio.h>

<grin>

> #include<stdio.h>
> void main()

<grin>

> {
> int in;
> printf("Enter a number:");

(FAQ) You need a

fflush (stdout);

to be sure that the output comes in time on all platforms.

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

Wow! What about reading you C-book one more time? What kind of a parameter
does scanf() expects with "%d" ? Certainely not an 'int'.

Some compilers like gcc track this kind of bug.

This kind of tricky stuff makes us think that scanf() is definitely not a
function for beginners. Actually, even experienced programmer mostly use
fgets() + strto[u]l().

> printf("ANSWER\n");
> printf("%d\n",in);
> }

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye

On Sat, 28 Jun 2003, bd wrote:
>
> On Sat, 28 Jun 2003 11:29:29 +0000, Emmanuel Delahaye wrote:
> > In 'comp.lang.c', (PRADEEP) wrote:
> [snip]
> >> printf("%d %d %d %d",i++,++i,i--,--i);
> >
> > NEVER use unary operators in parameters. The result is not defined.
>
> Not true. This is perfectly well-defined:
> printf("%d\n", i++);

Not to mention printf("%d\n", ++i), printf("%d\n", -i),
printf("%d\n", !i), printf("%d\n", (i++, ++i, i--, --i)),
printf("%d %d\n", ++i, ++j), and so on...
I think Emmanuel was just trying to say "don't use more than
one side effect to the same object at a time in parameter
lists, because the comma separator is not the comma operator,"
but that was too long for the newbie.

-Arthur

Arthur J. O'Dwyer

In article <bdjgud$bbi$>,
Richard Heathfield <> wrote:
>PRADEEP wrote:

>> {
>> int i=9;
>> printf("%d %d %d %d",i++,++i,i--,--i);
>
>Since the evaluation order of function arguments is unspecified, this could
>print any of many things. Since the behaviour of the program is undefined
>anyway, the possible range of outputs is quite astonishing.

Doesn't this line also invoke undefined behavior? I thought the only
time you were guaranteed sequence points between evaluation of arguments
was if each argument expression guaranteed a sequence point (f'rexample,
if each one was a function call of its own:
printf("%d %d",foo(i++),foo(i--));
). (Without looking it up, I thought that the rule was that (subject to
the as-if rule) arguments are evaluated sequentially in an unspecified
order.)

Of course, "Don't use the same variable in multiple function call
arguments if any of them have side effects" is probably a good rule to
go by. (Like the underscores at the beginning of identifiers rule,
this one probably forbids a few not-difficult-to-find cases that are
perfectly valid, but there's a good chance those are also the ones that
are confusing the first seventeen times you look at them, which is a
good enough reason to avoid legal code.)


dave

--
Dave Vandervies

Great humans are about as wrong as lay humans, but at least they are wrong
about *important* things.

Dave Vandervies

(Dave Vandervies) wrote in message news:<bdq4c1$ao3$>...
> In article <bdjgud$bbi$>,
> Richard Heathfield <> wrote:
> >PRADEEP wrote:
>
> >> {
> >> int i=9;
> >> printf("%d %d %d %d",i++,++i,i--,--i);
> >
> >Since the evaluation order of function arguments is unspecified, this could
> >print any of many things. Since the behaviour of the program is undefined
> >anyway, the possible range of outputs is quite astonishing.
>
> Doesn't this line also invoke undefined behavior?

Yes.

http://groups.google.com/groups?thre...ivernet.com.au

> I thought the only
> time you were guaranteed sequence points between evaluation of arguments
> was if each argument expression guaranteed a sequence point (f'rexample,
> if each one was a function call of its own:
> printf("%d %d",foo(i++),foo(i--));
> ). (Without looking it up, I thought that the rule was that (subject to
> the as-if rule) arguments are evaluated sequentially in an unspecified
> order.)

Not even that. Consider...

++ -- <seqn-pt> <seqn-pt> foo-call foo-call

--
Peter

Peter Nilsson

"Emmanuel Delahaye" <> wrote in message
news:Xns93A8893FE42FBhsnoservernet@130.133.1.4...
....
> get rid of that. Use getchar() if you inist...
> and add:
>
> return 0;
>
> > }

Is that return 0; necessary? I think I remember reading in the C99 standard
(at least) that main does not require it.

Also, Which standard C does this newsgroup follow these days? The C89 one or
the C99 one?

Jason

On Thu, 10 Jul 2003 16:17:12 +0100, in comp.lang.c , "Jason" <@>
wrote:

>Is that return 0; necessary? I think I remember reading in the C99 standard
>(at least) that main does not require it.

true, but its a good habit to always return something from a function
that has a return type.

>Also, Which standard C does this newsgroup follow these days? The C89 one or
>the C99 one?

Both.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Mark McIntyre