why am I getting runtime error? - c

I know that runtime error occurs when program consumes large memory or divide by 0 somewhere.
this is the code which prints all the numbers until user types 42.(does not print 42).
#include<stdio.h>
int main()
{
int n;
while(1)
{
scanf("%d",&n);
if(n==42)
break;
else
printf("%d",n);
}
}
please tell me why am I getting runtime error in such a simple code?

Your main function should return a int and you're not: that's why you get a Runtime Error. Here is the correct code:
#include <stdio.h>
#include <stdlib.h>
int main() {
int n = 0;
while(1) {
scanf("%d",&n);
if(n == 42)
break;
else
printf("%d",n);
}
return EXIT_SUCCESS;
}
You can also change return EXIT_SUCCESS; in return 0; if you don't want to include stdlib.h but here is why it's better.
You should also consider using another IDE than CodeChef. CodeBlocks or VisualStudio are better and more explicit with errors and warnings. And you should set you int n to 0 before using it.

This works perfectly fine as it is except when running on CodeChef.
According to the C standard (at least C99 and C11) a return 0 is implicit when main() ends without returning something. So even though it can be argued that it is a good idea to always have a return 0 at the end of main(), it is not wrong to skip it.
But that's not the case when running on CodeChef. For some reason they tread it as a run time error if main does not end with return 0.

Related

Not working properly. What am I missing?

the program is still very empty and "naked" because im just trying to get the logic out of the way before I actually start making functions. For some reason, whatever my argv[1] is, it always prints "The help message". What am I missing? I have a bad feeling about that for statement, but I dont know whats wrong with it.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void help()
{
printf("The help message\n");
exit(1);
}
void a()
{
printf("The a screen\n");
exit(1);
}
int main(int argc, char *argv[])
{
char recognised_commands[3] = {help(), a()};
int i;
if (argc != 2)
{
fprintf(stderr, "usage of sake: \"sake [option(s)]\"\nFor a full listing of all available commands type \"-help\" or \"--help\"\n\n");
exit(1);
}
for (i = recognised_commands[0]; i != recognised_commands; i++)
{
printf(argv[1]);
}
}
Edit 1: djikay: Fixed the -1 to 0,
Ricky: How do I correct the help() and the a() to only call the one the user inputs after the program name (EX: sake -a)? I also fixed the exit(0). Thanks
The line:
char recognised_commands[3] = {help(), a()};
causes both help and a to be called. help is called first, and it prints out the help message & exits the program.
char recognised_commands[3] = {help(), a()};
This line is definitely your issue. help() and a() are both being called, thus exiting your program.
Why are you trying to assign those function return values there? Both of the functions are void in return type, meaning they won't return anything anyways.
On a side note, calling exit() with 0 as the argument means your program exited without errors. I'd exit with 1 if it's because of an error (or even better, EXIT_SUCCESS and EXIT_FAILURE, respectively).

How to clear screen from simple C program?

#include <stdio.h>
#include <cstdlib>
rec();
main()
{
int a, fact;
char q, n, y;
printf("\nEnter any number ");
scanf("%d", & a);
fact = rec(a);
printf("Factorial value = %d\n", fact);
printf("do you want to exit.....(y/n):");
scanf("%s" ,&q);
if (q == 'n')
{
system("cls");
main();
}
else
return 0;
}
rec(int x)
{
int f;
if (x == 1)
return 1;
else
f = x * rec(x - 1);
return f;
}
I'm using code blocks but I don't know how to clear the screen. I searched then found system("cls"); within header file #include<cstdlib>, but it shows the error cstdlib: no such file of directory. What should I do ?
Change
#include <cstdlib>
to
#include <stdlib.h>
cstdlib is a C++ header file, and thus will be unusable in C.
Clearing the screen is outside the purview of a normal C program. It depends on the operating system.
For windows, you should look into conio.
For unix, look into curses or termios.
system() always launches a sub-shell which may or may not have any effect on the environment of the parent program. You do need a system-call, but not a system() call.
I didn't always know this. I once (long ago) suggested in comp.lang.c that someone should try system("exit"); to close the window around the DOS program. But that, of course, cannot work. And I was quickly advised to test my code before posting. :)
you have lots of problems in your code....
but for the specific problem, try #include <stdlib.h>
use the #include<stdlib.h> that's where the clear screen function is defined.
To use system("cls") you need the header <iostream>. This will allow all system() types to execute. Unsure if it is a C++ header file, but it works for the compiler that I use.

Any benefit of using assert instead of using a simple "if" ?

Given this code :
#include <stdio.h>
#include <assert.h>
void print_number(int* somePtr) {
assert (somePtr!=NULL);
printf ("%d\n",*somePtr);
}
int main ()
{
int a=1234;
int * b = NULL;
int * c = NULL;
b=&a;
print_number (c);
print_number (b);
return 0;
}
I can do this instead :
#include <stdio.h>
#include <assert.h>
void print_number(int* somePtr) {
if (somePtr != NULL)
printf ("%d\n",*somePtr);
// else do something
}
int main ()
{
int a=1234;
int * b = NULL;
int * c = NULL;
b=&a;
print_number (c);
print_number (b);
return 0;
}
So , what am I gaining by using assert ?
Regards
assert is to document your assumptions in the code. if statement is to handle different logical scenarios.
Now in your specific case, think from the point of view of the developer of the print_number() function.
For example when you write
void print_number(int* somePtr) {
assert (somePtr!=NULL);
printf ("%d\n",*somePtr);
}
you mean to say that,
In my print_number function I assume that always the pointer coming is not null. I would be very very surprised if this is null. I don't care to handle this scenario at all in my code.
But, if you write
void print_number(int* somePtr) {
if (somePtr != NULL)
printf ("%d\n",*somePtr);
// else do something
}
You seem to say that, in my print_number function, I expect people to pass a null pointer. And I know how to handle this situation and I do handle this with an else condition.
So, sometimes you will know how to handle certain situations and you want to do that. Then, use if.
Sometimes, you assume that something will not happen and you don't care to handle it. You just express your surprise and stop your program execution there with assert.
The difference is that assert is enabled only for debug build; it is not enabled for release build (i.e when NDEBUG is defined), which means in the release build there will be no check; as a result, your code will be little bit faster, compared to the one in which you use if condition which remains in the release build as well.
That means, assert is used to check common errors when you write the code, and catch them as soon as possible, in the development phase itself.
Lots of reasons:
Asserts are usually removed for release builds.
Asserts will report failure information to the client. if() does nothing by itself.
Because asserts are usually macros, you can also get code information about the failing assertion.
Assert is more semantically clear than if().
If assertion fails, you will see the output containing the failed assertion itself, plus the function and the line of the failed assert, something like:
test: main.cpp:9: int main(): Assertion `0==1' failed.
So, if your program crashes in runtime, you will see the exact reason and location of the crash.
There's a big article about assertions in wiki.
Assert will inform you that something wrong happend, possibly error to be fixed. In debug mode it will break and show callstack that will help you with fixing bug. So its a good practice to use. I would actually use if() and assert, because in Release your asserts should be turned off:
void print_number(int* somePtr) {
assert(somePtr != NULL);
if (somePtr != NULL)
printf ("%d\n",*somePtr);
// else do something
}
in " // else do something " you might think of throwing exception or returning error code.
Listen If Your (if) statement becomes True or False so compiler go for the next instructions.
But in assert.h when your statement becomes false "Program Terminates immediately" with assertion message.
EXAMPLE :*
#include <assert.h> #include <stdio.h>
int main () {
int a;
printf("Enter an integer value: "); scanf("%d", &a); assert(a >= 10);
printf("Integer entered is %d\n", a);
return(0); }

How codepad know about infinite loop?

I tried the following code:
#include<stdio.h>
main()
{
int i;
for(i=1;i<50;i++){
printf("Hello World");
}
}
and
#include<stdio.h>
main()
{
int i;
while(1){
printf("Hello World");
}
}
codepad shows "Time out". Does it have syntax-checks or does it simply check if my program takes up too much time?
It looks like codepad has limits for resources used by submitted programs, and stops the ones that are beyond them.
Your infinite loop program exceeds the time limit, and is stopped with "Time out" message. So there's nothing related to syntax checking here.

This program shows segmentation fault,I think infinite recursion occurs.Can you suggest me the correction

#include <stdio.h>
int f(int n)
{
if(n <= 1)
return 1;
if(n%2 == 0)
return f(n/2);
return f((n-1)/2) + f((n-1)/2+1);
}
/*To test above function */
int main()
{
int a = 11;
printf("%d", f(11));
getchar();
return 0;
}
Why not just to trace it in debugger, and see what's goind wrong?
This code compiles and runs just fine for me. The result is 5. Have you tried the explicit keyword to see if it is an optimization flaw? EDIT: If the problem is getchar() the problem could be your operating system at run time or your library at compile time. Is that a clean compile? What compiler are you using?
There is nothing wrong with this program, it doesn't give me any sort of infinite loop or seg fault (and since you have the <=1 condition, the program will not crash out for sure).
Something tells me that your machine here is faulty for some reason... maybe lack of memory or confilcting programs? Or even compiler freaking out? (that one already happened to me). Try to run the code on other machine if possible and find out if it still gives you seg fault or not

Resources