i donno the problem

[ashwin700]

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

[Harold Aptroot]

"ashwin700" <mi**************@gmail.comwrote in message
news:ac**********************************@a3g2000p rm.googlegroups.com...

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something like
"(1 is smaller or equal to n) is small or equal to 100" which is allways
True because any outcome of the expression "(1 is smaller or equal to n)"
will be smaller or equal to 100 (it will be either 1 or 0)
Therefore it will keep printing n, forever, n is functionally random and
will not change.

you may want to try

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(n<=100 && n>0)
{
printf("%d ",n);
}
}

it will still not make sense but atleast the condition will do what you mean

[Harold Aptroot]

"Harold Aptroot" <ha************@gmail.comwrote in message
news:63***************************@cache100.multik abel.net...

"ashwin700" <mi**************@gmail.comwrote in message
news:ac**********************************@a3g2000p rm.googlegroups.com...

>#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something
like "(1 is smaller or equal to n) is small or equal to 100" which is
allways True because any outcome of the expression "(1 is smaller or equal
to n)" will be smaller or equal to 100 (it will be either 1 or 0)

actually, for True any value other than 0 would be allowed, but at least
with your compiler True ends up being smaller of equal to 100 (it could be
42 or -1 or -666 however)

Therefore it will keep printing n, forever, n is functionally random and
will not change.

you may want to try

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(n<=100 && n>0)
{
printf("%d ",n);
}
}

it will still not make sense but atleast the condition will do what you
mean

[sh.vipin]

On Sep 14, 5:14*pm, "Harold Aptroot" <[e-mail]:

"ashwin700" <[e-mail] in message

news:ac**********************************@a3g2000p rm.googlegroups.com...

#include<stdio.h>
#include<conio.h>
main()
{
* *int n;
* *while(1<=n<=100)
* *{
* * * printf("%d ",n);
* *}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something like
"(1 is smaller or equal to n) is small or equal to 100" which is allways
True because any outcome of the expression "(1 is smaller or equal to n)"
will be smaller or equal to 100 (it will be either 1 or 0)
Therefore it will keep printing n, forever, n is functionally random and
will not change.

you may want to try

#include<stdio.h>
#include<conio.h>
main()
{
* *int n;
* *while(n<=100 && n>0)
* *{
* * * printf("%d ",n);
* *}

}

Here also, it will print either infinitely or will not print
anything.
see, n is not being changed at all.
so really need to check the purpose of program

--
vIpIn

[vippstar]

On Sep 14, 3:19 pm, "Harold Aptroot" <[e-mail]:

"Harold Aptroot" <[e-mail] in message

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something
like "(1 is smaller or equal to n) is small or equal to 100" which is
allways True because any outcome of the expression "(1 is smaller or equal
to n)" will be smaller or equal to 100 (it will be either 1 or 0)

actually, for True any value other than 0 would be allowed, but at least
with your compiler True ends up being smaller of equal to 100 (it could be
42 or -1 or -666 however)

Nonsense. Comparison operators yield 0 or 1.

[vippstar]

On Sep 14, 3:07 pm, ashwin700 <[e-mail]:

#include<stdio.h>
#include<conio.h>

<conio.his not standard. Do not include it, or post in a more
appropriate group. (presumably some microsoft group)

main()

Valid only in C89. Change it to int main(void).
("implicit int" was removed in C99)

{
int n;
while(1<=n<=100)

n is not initialized. You invoke undefined behavior.
Assuming n was initialized, this expression is always true.
See question 3.13 of the C-FAQ. <http://c-faq.com/>

<snip rest code>

[Harold Aptroot]

<sh******@gmail.comwrote in message
news:ee**********************************@r15g2000 prd.googlegroups.com...

On Sep 14, 5:14 pm, "Harold Aptroot" <[e-mail]:

>"ashwin700" <[e-mail] in message

news:ac**********************************@a3g2000 prm.googlegroups.com...

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something
like
"(1 is smaller or equal to n) is small or equal to 100" which is allways
True because any outcome of the expression "(1 is smaller or equal to n)"
will be smaller or equal to 100 (it will be either 1 or 0)
Therefore it will keep printing n, forever, n is functionally random and
will not change.

you may want to try

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(n<=100 && n>0)
{
printf("%d ",n);
}

}

Here also, it will print either infinitely or will not print
anything.
see, n is not being changed at all.
so really need to check the purpose of program

Ah yes it will still not do anything useful - but atleast it will not
"ignore" the condition

[Bartc]

"ashwin700" <mi**************@gmail.comwrote in message
news:ac**********************************@a3g2000p rm.googlegroups.com...

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

Not sure what you're trying to do but look at these alternatives:

n=24; /* must be initialised */

if (1<=n && n<=100)
printf("%d ",n);

n=24;

while (1<=n && n<=100) {
printf("%d ",n);
++n;
}

--
Bartc

[sh.vipin]

On Sep 14, 5:07*pm, ashwin700 <[e-mail]:

#include<stdio.h>
#include<conio.h>
main()
{
* * int n;
* * while(1<=n<=100)
* * {
* * * *printf("%d ",n);
* * }

}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

it will always be in infinite loop
evaluation 1<=n<=100 is evaluated according to left to right
associativity

1<=n will always result in either 0 or 1
this resulting value (0 or 1) will always be <= 100

you can check the same by setting n =0; before
while(1<=n<=100)

--
vIpIn

[Richard]

vi******@gmail.com writes:

On Sep 14, 3:19 pm, "Harold Aptroot" <[e-mail]:

>"Harold Aptroot" <[e-mail] in message

n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something
like "(1 is smaller or equal to n) is small or equal to 100" which is
allways True because any outcome of the expression "(1 is smaller or equal
to n)" will be smaller or equal to 100 (it will be either 1 or 0)

actually, for True any value other than 0 would be allowed, but at least
with your compiler True ends up being smaller of equal to 100 (it could be
42 or -1 or -666 however)

Nonsense. Comparison operators yield 0 or 1.

You are being purposely dense.

You know full well what he means

if(func(t))...

So long as the return is non zero ...

Context is another issue.

[Ben Bacarisse]

Richard<rg****@gmail.comwrites:

vi******@gmail.com writes:

>On Sep 14, 3:19 pm, "Harold Aptroot" <[e-mail]:

>>"Harold Aptroot" <[e-mail] in message
n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather something
like "(1 is smaller or equal to n) is small or equal to 100" which is
allways True because any outcome of the expression "(1 is smaller or equal
to n)" will be smaller or equal to 100 (it will be either 1 or 0)

actually, for True any value other than 0 would be allowed, but at least
with your compiler True ends up being smaller of equal to 100 (it could be
42 or -1 or -666 however)

Nonsense. Comparison operators yield 0 or 1.

You are being purposely dense.

You know full well what he means

if(func(t))...

So long as the return is non zero ...

Context is another issue.

That does not seem to what he meant at all. "at least with your
compiler" suggest to me he was correcting what he thought was an error
in his original answer.

--
Ben.

[Andrew Poelstra]

On 2008-09-14, ashwin700 <mi**************@gmail.comwrote:

#include<stdio.h>
#include<conio.h>
main()
{
int n;
while(1<=n<=100)
{
printf("%d ",n);
}
}

Now this code prints something like 783 infinitely.....if the number
is between 1 to 100 then it should be printed infinetely else it
should not be printed at all///why is it so happening???

Does your compiler not give you some warnings about
this code? It is not required to, but I think you
need a better compiler (or better compilation flags)
if this is the case.

Mine says:

usenet.c:2:18: error: conio.h: No such file or directory
usenet.c:4: warning: return type defaults to ‘int’
usenet.c: In function ‘main’:
usenet.c:6: warning: comparisons like X<=Y<=Z do not have
their mathematical meaning

(Though with no command-line arguments, it says nothing.)

--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net

[James Kuyper]

Andrew Poelstra wrote:
....

Does your compiler not give you some warnings about
this code? It is not required to, but I think you
need a better compiler (or better compilation flags)
if this is the case.

Mine says:

....

(Though with no command-line arguments, it says nothing.)

That's odd - mine says

gcc - no input files

;-)

[Harold Aptroot]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

Richard<rg****@gmail.comwrites:

>vi******@gmail.com writes:

>>On Sep 14, 3:19 pm, "Harold Aptroot" <[e-mail]:
"Harold Aptroot" <[e-mail] in message
n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather
something
like "(1 is smaller or equal to n) is small or equal to 100" which is
allways True because any outcome of the expression "(1 is smaller or
equal
to n)" will be smaller or equal to 100 (it will be either 1 or 0)

actually, for True any value other than 0 would be allowed, but at
least
with your compiler True ends up being smaller of equal to 100 (it could
be
42 or -1 or -666 however)

Nonsense. Comparison operators yield 0 or 1.

You are being purposely dense.

You know full well what he means

if(func(t))...

So long as the return is non zero ...

Context is another issue.

That does not seem to what he meant at all. "at least with your
compiler" suggest to me he was correcting what he thought was an error
in his original answer.

Ah I am sorry that my bad english has caused an argument..
I just meant that if there had been an other "thing meant as bool" there it
could easily have been 42 and the same effect would happen
if that makes any sense to you..

[Barry Schwarz]

On Sun, 14 Sep 2008 14:14:35 +0200, "Harold Aptroot"
<ha************@gmail.comwrote:

>you may want to try

#include<stdio.h>
#include<conio.h>

Why are you including a non-standard header that you don't use?

>main()

Implicit return values have been removed from the language.

>{
int n;
while(n<=100 && n>0)

This invokes undefined behavior.

{
printf("%d ",n);
}

main needs to return a value of the promised type.

>}

it will still not make sense but atleast the condition will do what you mean

--
Remove del for email

[Nick Keighley]

On 14 Sep, 18:41, "Harold Aptroot" <[e-mail]:

"Ben Bacarisse" <[e-mail] in message
news:87************@bsb.me.uk...

Richard<[e-mail]:

[e-mail] writes:
On Sep 14, 3:19 pm, "Harold Aptroot" <[e-mail]:
"Harold Aptroot" <[e-mail] in messag

>n is not initialized (so it could be anything, including 783)
"1<=n<=100" does Not mean "n is between 1 and 100" but rather
something like "(1 is smaller or equal to n) is small or equal
to 100" which is allways True because any outcome of the
expression "(1 is smaller or equal to n)" will be smaller or
equal to 100 (it will be either 1 or 0)

>>actually, for True any value other than 0 would be allowed,

not in a compliant C compiler!

>>but
at least with your compiler True ends up being smaller of equal
to 100 (it could be 42 or -1 or -666 however)

>Nonsense. Comparison operators yield 0 or 1.

You are being purposely dense.

I don't think so

You know full well what he means

it confused me. And a very common (but incorrect
belief) is that boolean operators in C can yeild "non-zero"
for true, which seems to mean "any non-zero value".
I correct this misapprehension when I encounter it.

Re-reading Mr Aptroot, I'm still not convinced
he doesn't suffer from misapplication-of-true-is-non-zero
syndrome.

if(func(t))...

So long as the return is non zero ...

Context is another issue.

and the context is (1 <= n <= 100)

That does not seem to what he meant at all. *"at least with your
compiler" suggest to me he was correcting what he thought was an error
in his original answer.

Ah I am sorry that my bad english has caused an argument..
I just meant that if there had been an other "thing meant as bool"
there it
could easily have been 42 and the same effect would happen
if that makes any sense to you

--
Nick Keighley