I was assuming that the sizeof(int) will give the number of digits in the number,but
now I know I was wrong(It returns the size of the var in bytes).
Is there a way(builtin library functions,methods..etc.) to find the number of digits in the integer?Or I have to write a separate function for that.

You could also convert the number to a string and count the characters or get the strlen();

Is that giving too much away?

Food for thought: converting a number to a string involves locating and interpreting each digit, which is only a short leap from counting the digits. So you're adding unnecessary steps to the process, presumably for the sake of simplicity. There's no doubt that it's simple, but all of the work you're doing is likely to be dreadfully slow relative to other solutions.

for loop and the i variable are not good fit for the purpose. I suggest while instead.

I know how to use while loop but have never used it like
this way: while(i) when I write my own(though I have seen others' many times)
instead I only use while loops like
this way : while(i<3)
What does the line

It is little hackish as it uses the knowledge that 0 is considered False while all other values are considered True, so it is same as:

while(checknum != 0)

So you understood it correctly.

Actually I would also rename checknum as numbers_left and checknum2 as reversed_number. Also better to put the action (the while loop) in separate is_palindrome_number funcion, which has no input or output as you had done in your code.

Actually, Tony, I wouldn't recommend that solution at all. By building the reversed number you're limiting the range of possible input values because the reversed number might overflow. For example, an original of 12,345 would be acceptable as an original, but when reversed to 54,321 would overflow a 16-bit int.

Somewhat less importantly, but still of concern is trailing zeros will not become leading zeros, they'll be removed entirely such that the algorithm would hit a false negative. This may or may not be a bug, depending on the requirements. If it's a bug, the best solution is to accept a string rather than an int to avoid leading zeros being ignored. If still accepting an int, you need to decide if trailing zeros are to be considered significant, since a number with trailing zeros would never be a palindrome. In my opinion that's something that would be up to the caller.

A better solution would be to merge the steps of extracting digits and testing them, much like you would do with a string:

That's an oversight on my part. ;) It's easily fixed, but since I didn't post the implementation for my helper functions (to avoid giving everything away), you can just change the line to this and pretend it works:

Here is my basic code simplified from general palindrome code, I added check for number. Coded my own as the googled code looked so stupid. I consider you showing effort by posting running code earlier, so this is fully working code. Got mystified with the newline stuff from fgets for a while.

That question can be generalized to how can we accept strings of arbitrary length? You can still use fgets(), but there's more work involved because now we need to account for strings that exceed the buffer size. Obviously this involves dynamic allocation of memory:

Is there any particular reason you aren't simply initializing the pointers?

char* front = sentence;
char* back = &sentence[strlen(sentence) - 1];

printf("enter the number: ");

Unless you're printing a newline, fflush() is warranted to ensure that the prompt shows before fgets() blocks for input:

printf("enter the number: ");
fflush(stdout);

num[strlen(num)-1] = '\0';

fgets() will not store a newline if the buffer is full, so it's better to check that you have a newline before overwriting it. The purpose of that newline is so that we can verify whether or not a partial line was read. You'll most often see just a conditional removal, which is fine in example code:

It's not really a good practice for a function to make unwarranted assumptions about the arguments. The assumption that BUFSIZ is in any way meaningful for string p is unwarranted, and actually puts a limitation on callers to provide at least that much or guarantee that the number of digits doesn't exceed that limit.

Since we're already assuming that p represents a valid string, there's no need to do any extra tests. The first half of the condition will fail on '\0'. Likewise, your games with BUFSIZ later in the function are an unneeded complication:

Though I would also point out in a code review that your get_number_len() function pulls double duty of counting digits and removing a trailing newline, which isn't a good design, especially since the removal of a trailing newline is silent (only knowable by reading the comment).

int is_palindrome(char* number, int number_length){

Once again, number isn't modified so you should make it a pointer to const char. Const correctness is important because it protects you from yourself and gives callers of the function confidence in passing string literals.

Ack! I double checked and my statement about fflush() quite clearly had an example of fflush(stdout) . Not only does fflush(stdin) not do what you want in this case, it's also undefined behavior because fflush() is only specified to work on output streams.

Though I would also point out in a code review that your get_number_len() function pulls double duty of counting digits and removing a trailing newline, which isn't a good design, especially since the removal of a trailing newline is silent (only knowable by reading the comment).

On the contrary, by magic numbers 0 and -1 as error codes, it loudly complains if it can not remove the newline or non-number is encountered. I hate that function that surely must traverse through all string and so know the length of string throws away the information and force us to scan the string again to get length of the string in palindrome function or do another scan of string for newline or not checking. So I included it in function. As function name

seemed little unusable, so I did compromize with naming added by comment in function for input (which is newline terminated number). Side effect of ending the string similartly to strtok seemed reasonable trade off, instead of leaving the caller to do manually the operation every time after receiving length > 0. Of course in principle I would agree that side effects are nasty, but C language seems to be full of them.

Changed function name with end _len clearly points that this is not is_number function, but is function to verify valid number ending in newline while counting the length of number and returning magic number return codes 0 and -1. It is not accepting zero terminated input except in rare case that number is exactly the length of buffer - 1 so that newline does not fit but null does, I tested this by doing global replace of BUF_SIZ by small constant to make it easier to test the corner case of exactly maximum length of input with no space for newline available. For me it is logical as returning length of number (be it is in string format) does not make sense if input is not valid number. Input validity is not assumed, of course it is assumed to point one string somewhere.

I would have liked to eliminate the checking the limit. Your version of function does not satisfy the specification as it does not tell input overflowed the buffer, but checks the beginning of string for palindrome silently ignoring the invalidity of number.
(Tested by adding

// debug, remove after debug !!!
#undef BUFSIZ
#define BUFSIZ 5

after the includes, result of my main program:

enter the number (max length 4): 122132342342
1221, number of length 4, is palindrome
Process returned 0 (0x0) execution time : 11.688 s
Press any key to continue.

)
Your version also accepts number without newline termination.

By the error handling of 0 for not valid number (available as magic number as empty string is not valid for number) and -1 indicates input overflowing the buffer and not including the newline, so it will be quickly be eliminated without extra scan for finding the newline in string.

Ack! I double checked and my statement about fflush() quite clearly had an example of fflush(stdout) . Not only does fflush(stdin) not do what you want in this case, it's also undefined behavior because fflush() is only specified to work on output streams.

I did it because of the reason in text which clearly talked about problem getting input from user without fflush, which does not necessary have anything to do with output. Why should I do something stdout to clear stdin for input? I did not get that you were talking problem of outputting the prompt before input is expected from user, not problem of reading input. I should have read your code for fix also, of course.