Printable View
ok guys!
my intention was not that.it was not a homework.
anyways
i have done them
but there is a problem
the following code goes to a infinite loop
i am not getiing it
main()
{unsigned int i=10;
while(i>=0){
printf("%u",i)
i--;}
}
also this one
for (i=0;i=10;i+=2)
printf("Hi\\n");
difference b/w \n and \\n?
Ok, now I know you're just not paying attention. I've already given you the Big Red Square for another post where you didn't use code tags. Unfortunately, I have to spread it around more before I can give you another one. So I'll just chew you out again for it. USE CODE TAGS!
How about you spend ten seconds and find out for yourself?Quote:
difference b/w \n and \\n?
Quzah.Code:#include <stdio.h>
int main ( void )
{
printf("this is with two slashes: \'\\n\', and this is with one slash: \'\n\'.");
return 0;
}
First off, edit your post and put [ CODE ] [ /CODE ] tags in. Do it now.
Second, I'll offer some help. In the first code snippet
Your missing something in the while loop. If you throw this in a compiler, it won't compile.Code:int main()
{
unsigned int i=10;
while(i>=0)
{
printf("%u",i)
i--;
}
return 0;
}
//Edited for clarity
In the second code snippet, you are suffering from a very very common typo.
Look closely at the condition for the for loop...Code:for (i=0;i=10;i+=2)
printf("Hi\\n");
And just for the record, a very safe coding practice that you should get in the habit of doing is to use the following in your conditionals...
PKCode:int main()
{
int i = 10;
if (10 == i)
{
//this is the safe way. If you forget a =, the compiler will tell you
}
while (i == 10)
{
//If you forget an =, then i will be set to 10, and since all non 0 values are TRUE, the loop goes on forever!
}
return 0;
}
A unsigned integer can be lower than zero... :confused: :confused: :confused: :confused:
It never hurts to check...what if the type gets changed to an int later for some reason? Makes it less likely a bug appears when changes are made and clearly states the condition being checked, even if it is redundant.Quote:
Originally Posted by xErath
Plus, a good compiler should recongnize that fact and not put in the extra check...I hope.
What happens when i is 0? it satisfies i >=0, so the loop exectues again.... now what happens to i? does the loop keep on going? think about itQuote:
Originally Posted by pablo615
Oh, thats what you meant...uhhh, I missed that. It will roll over and become all 1s (0xFFFFFFFF for 32 bit int) and the loop will just keep on going.
Which should have been obvious since he is printing the result. It would look something like
10
9
8
7
6
5
4
3
2
1
0
<some really big number> -> max value for unsigned integer
<that really big number-1>
etc
etc
Unsigned integers are just that. They have no sign. The sign bit is in the higest order bit but it is used as a numerical value instead of a sign. The max value for a 16-bit unsigned integer is 65535 or 0xFFFF. For a 32-bit value it is 0xFFFFFFFF or something like 4,200,.... some really big number that I forget what it is. Your MSVC will tell you the upper limit of a 32-bit unsigned integer. So your loop will never terminate...it will always be greater than or equal to 0 since your variable can never be negative.
And please don't do this:
If you can't remember an equals sign then you prob ought to go to the doctor and get your head checked. Better than that if your compiler flags the line as an error and you cannot see that you forgot an equals sign...definitely admit yourself to the emergency room. You've had a massive brain failure.Code:int main()
{
int i = 10;
if (10 == i)
{
//this is the safe way. If you forget a =, the compiler will tell you
}
while (i == 10)
{
//If you forget an =, then i will be set to 10,
//and since all non 0 values are TRUE, the loop goes on forever!
}
return 0;
}
I give up.
did this not give you an overflow warning?
I don't think it would flag a warning. It's not a signed to unsigned comparison so that wouldn't flag it. Zero is unsigned (not actually, but you get the idea) and his data type is unsigned so I don't think that would cause a warning.
Might be one of those errors that the compiler will not catch because after all, it is syntactically correct and legal. It's just using flawed logic and unfortunately there are some logic errors that compilers just won't catch.
Technically this is an underflow. But again I don't think it will flag any warning because the variable will never lose any significant digits, it's just wrapping the data type. It might say something about possible underflow, but again it might not.
And it's really not an underflow because the data type can represent everything he has specified in the code. An unsigned int can be 0 and can be <=10 and it also can be 0xFFFF.
A good illustration about why it is so important to use the correct data type. Imagine if this error were part of a rendering loop or calculation loop in a huge program. Very hard to catch this error, especially if there was more code in the program.
C or C++ programs won't give runtime "overflow" warnings or errors for integer addition, subtraction or multiplication. Bits more significant than the size of the item are simply lost.Quote:
Originally Posted by misplaced
Some compilers (Borland bcc32, for example) might give a compile-time warning like:
That would be niceQuote:
Warning W8008 d.c 3: Condition is always true in function main
lint gives the following:
These are good tools, but the best tool is your brain: how could the loop go infinite when the loop condition isQuote:
d.c:3:7: Comparison of unsigned value involving zero: i >= 0
An unsigned value is used in a comparison with zero in a way that is either a
bug or confusing. (Use -unsignedcompare to inhibit warning)
"i >= 0"
Three possibilities that I can think of (there may be more, but I think you get the idea):
1. The computer is defective; can't execute code properly.
2. The compiler is defective; can't create a valid executable from valid source code.
3. The variable "i" is always greater than equal to 0.
Let's see, now, which do I think is more likely?
Not 1 (everything else works OK)
Not 2 ("Hello, world", compiles and executes OK)
Not 3 since I perform "i--" every time through the loop, and "i" is clearly declared to be an unsigned int.
Wait! Hold everything! The value of an unsigned int is always greater than or equal to 0. Oh, man, what a relief! I don't have to throw away my computer or get a new C compiler, just fix the code.
Regards,
Dave
Now thats just plain wrong. Typos happen all the time, even to the best of us. And its a human flaw that when your reading through something and expecting to see something, like 2 = signs, you will see 2, even if there is only one. Sure, when we read other peoples code, we see all the flaws because we don't know what to expect, so we actually read it.Quote:
Originally Posted by Bubba
This coding practice can save you a headache, especially for beginners. The compiler won't flag a valid assignment in a conditional.