C program please help

[alajaji]

Hey guys am new in C, could anyone help me with this?

write a program that store the values x and 76.1 in seperate memory cells, your program should get the values as data itmes and display them again for the user when done.

thanks

[shaji]

:)
//include directives
main()
{
int * num1;
float *num2;
printf("enter intiger number:");
scanf("%d", num1);
printf("enter float number:");
scanf("%f",num2);
//display the numbers
printf("first number :%d\n",num1);
printf("first number :%f\n",num2);
}

[Narue]

shaji: Your code is horribly, horribly broken. Before you try to teach C, please learn it first.

alajaji: We don't do homework. Show your attempt.

[shaji]

hi naure,
we all know the question posted by this man is a very simple (seems he is currently attending his pre-degree course) home work.
what will happen if i posted the currect code for that problem??? he will cut ,paste, compile and run that is all .it finishes there.
and what will happen if the code is buggy? he will try to debug it and it will help the person to learn more about C Code. i'm sure Mr/Mrs.Narure know that debugging the right strategy to learn programming. copy aome code from somewhere and runnning wont help any person to learn programming. am i right naure?
and my self i'm not a beginer in the field. am experienced in teaching . i taught Graduate level engg. students for 2 and half years in an indian engineering college. right know am working as a software engineer in image processing domain.
thank you naure
regards
shaji

[Narue]

>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?

[shaji]

>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?

dear naure,
i respect u as a senior poster here. the code snippet i posted contains only 6 or 7 statements and as i said earlier it is a verysimple homework problem and the bugs are intentional. u can not demonstarte example for classical bug in that snippet. the bugs i introduced in it are those usually made by junior programming students .

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 ..if the student is really interested to learn programming and he/she has the basic skills he/she will sure try to debug the code . we know the fact " u can improve ur physiq ,spending some time in gym..like u can improve ur programming skill just by doing debugging" . cut -and- paste method wont help in any manner.

I taught 'operating system design' ,'microprocessors' , 'Data structures' and 'image processing algorithms' .and right now am working in image processing domain . and i dont think it is necessary to disclose further personal details for u. this site is great. if site admin thinks that am shouting out lie and bugs here she may contact me to get more details about me [mmm.... including my certifates and others documents...but really am not humble....am proud of being a programmer]

thank u naure and friends

[Stoned_coder]

Im with narue on this one. I cannot believe you have taught operating system design yet code a small sample with 9 lines on which 2-3 will cause errors. You seem to think the OP will have some clue as to how to fix your code. Trust me if they couldn't write that program they will have no idea why its flawed. Debugging is not the way to learn programming, practice is. What you could have done would have been to show snippets or pseudocode to gently prod the OP in the right direction.

[Narue]

>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:

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:

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 bastard instead of a stupid bastard. 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:

{

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.

[shaji]

hi naure,
main() <- was not intentional i agreed but others were. but i just overestimate the skill of a junior programming-student. i agree that i did wrong. and very sorry about that. thank u for spending ur valuable time to reply to my post. let's give it up here .
regards
shaji

>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:

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:

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 bastard instead of a stupid bastard. 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:

{

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.