>am i right naure?
No, you're not. Debugging is indeed a valuable skill, but if you give someone code that clearly does not work and it's obvious that they don't have the skills to debug it, they'll simply walk away and try to get help elsewhere. We don't play like that around here. Instead of giving out broken code, we try our best to promote good habits with high quality code. If someone asks for a homework solution, simply don't give it to them. That's a better solution than posting the crap code that you did.

>and my self i'm not a beginer in the field.
Okay, point out all of the errors in your code. If you get them all then I'll agree that you're not a beginner and that the problems were intentional rather than the result of ignorance on your part. But somehow I doubt that you realize how many problems there really are in that snippet.

>i taught Graduate level engg. students for 2 and half years
And what part of that means that you're qualified to teach programming?

>the snippet is buggy i agreed but u can compile it and execute .u
>wont get the correct output and that is ..that is it ..
Actually, you can't compile it without modification. Most compilers will fail to run it without giving some form of segmentation or access violation. Ignoring that, you've introduced undefined and implementation-defined behavior. You're relying on compiler extensions, and even if in the unlikely event that all of these horrible problems don't send the program down in flames, the wrong output will be formatted poorly. Let's look at all of the problems that you seem to think a beginner can recognize, understand, and correct:

>//include directives
First, this assumes the beginner knows what an include directive is, what the syntax is, and which headers to include in the directive. Second, it's highly unlikely that you or the OP are compiling as C99, therefore the use of BCPL style comments is either illegal and will fail to compile, or a non-portable compiler extension. This is only line 1 by the way. It gets worse.

>main()
This is technically legal in C89, but illegal in C99 and poor style in C89. You're promoting a common misconception that you yourself have made, where not supplying a return value assumes no return value when it in fact returns an integer. A strictly correct definition of main taking no arguments is:

C Syntax (Toggle Plain Text)

int main ( void )

int main ( void )

>printf("enter intiger number:");
Your spelling and grammar bites, but I can forgive that. What I can't forgive is the system-dependent behavior that you create when you fail to properly flush stdout after a user prompt. You either need to print a newline to force a stream flush, or call fflush:

C Syntax (Toggle Plain Text)

printf ( "Enter an integer: " );
fflush ( stdout );

printf ( "Enter an integer: " ); fflush ( stdout );

>scanf("%d", num1);
This will break. It doesn't matter if it's loud or silent, but it will break. num1 is a pointer. num1 points to an indeterminate address. That address is probably outside of your address space, it's probably being used for something else, and that something else is probably important. This line is very broken.

>printf("enter float number:");
Same problem as above. This line assumes that the terminal (assuming it's even present) will flush the stream in time for the user to see it and know what to do before the program stops to wait for input.

>scanf("%f",num2);
Same problem as above, this call to scanf is undefined because num2 doesn't point to memory that you are sure you own. This is probably one of your intentional mistakes, which means you're a sadistic ******* instead of a stupid *******. Please tell me what part of throwing a beginner to the wolves with subtle memory errors is a beneficial learning experience.

>//display the numbers
This may not compile, and if it does it's not portable unless you're using C99, in which case your code definitely won't compile because other parts of the code have constraint violations for C99.

>printf("first number :%d\n",num1);
This is broken. num1 is a pointer, but you treat it like an integer. A pointer need not be representable as an integer, so this could fail mysteriously. Otherwise it will simply print an address, an indeterminate address since you never set num1 to point to memory that you own. I imagine this is another one of your little intentional errors, but I get the feeling you have no idea how bad it really is. You probably just thought it would print an address.

>printf("first number :%f\n",num2);
This is broken. num2 is a pointer, but you treat it like a floating-point type. This is even worse than treating an address as an integer. You probably intended this one too, but once again I question your ability to realize how deep these errors go.

>}
Congratulations, this one line makes the entire program undefined (even if the other errors didn't already). main returns an int. It doesn't matter how you try to define main, it ALWAYS returns an int in a hosted implementation. If you fail to return an int, you invoke undefined behavior. If you define main to return something other than an int, you invoke undefined behavior or implementation-defined behavior if the implementation allows it. If the implementation doesn't allow it, your code may not even compile. There is so much wrong with defining main incorrectly or failing to return a value that I can't even begin to chew you out for doing it. I would bet my next paycheck that this is not one of your intentional errors.

But maybe I'm being too negative. There is one line in your program that is perfectly legal and correct. It doesn't invoke undefined behavior or rely on implementation extensions. It doesn't have incorrect output or rely on system dependencies. Where this one line is concerned, you're the ideal programmer. This is the line:

C Syntax (Toggle Plain Text)

{

{

Everything else is wrong.

>I taught 'operating system design' ,'microprocessors' , 'Data structures' and 'image processing algorithms'
At least you're consistent with the so-called "professors" that I've had to repeatedly correct over the years.