1

So im answering an assignment question in c and for some reason when I run it in codeblocks or even C lion I get a different and wrong answer than when I run it on Repl.it online. I copied and pasted the code so there are no errors or differences. The question itself requires u to enter a 12 digit ISBN number then calculate the product by takin (1st number) X 1 + (second number) X 3 and so on then taking the mod of the sum and subtracting from 10 and calculate the last digit.

Ex the number 978030640615 should give the product as 93 and last digit as 7

Below is my code for code blocks:

#include <stdio.h>
int main(void) {
long num1 = 0;
int num2 =0;
int sum =0;
int n = 0;

printf("Enter number :\n");
scanf("%ld",&num1);
for (int i= 0 ; i<12 ; i++){
   num2 = 0;

   num2 = num1%10;
   num1  = num1/10;
   n +=1;
   if (n%2 == 0){
      num2 = num2*1;
      //printf("%d" , num3);
   }
   else {
      num2 = num2*3;
      //printf("%d", num2);
   }
   sum = num2+sum;

 }
 printf("\n" "%d", sum);
 num2 = sum%10;
 num2=  10 - num2;
 printf("\n" "%d", num2);

}

and the output is -63 and 13

My code for Repl.it is the same as the one from codeblocks I copied and pasted it but i get 93 and 7 as the answer

Alex bob
  • 11
  • 2
  • If the code is functionally equivalent and still produces different results, the likely cause of trouble is that you've invoked _undefined behaviour_ in one, if not both, programs. – Jonathan Leffler Oct 07 '19 at 19:14
  • `num2 = num2*1` - this is pointless... – Eugene Sh. Oct 07 '19 at 19:14
  • 5
    Perhaps `long` is 32 bits on one system and 64 bits on the other. You are using a 12-digit number which won't fit 32 bits. – Weather Vane Oct 07 '19 at 19:14
  • 1
    Variables `n` and `i` are tracking over the same sequence of numbers; one of them is superfluous. Also, in general, it is better to end printing operations with a newline than to start them with a newline. At least, when run on the command line in a terminal, the second number typically gets mixed up with the next shell prompt. – Jonathan Leffler Oct 07 '19 at 19:19
  • 1
    Note that you can check whether you've got 32-bit vs 64-bit problems by adding: `printf("ISBN: %ld\n", num1);` after the input. If you don't see what you thought you entered, you know you've got problems. Echoing input is a very basic debugging technique — also available if you use a debugger instead. – Jonathan Leffler Oct 07 '19 at 19:23
  • 2
    Also note that you might find it easier to process the ISBN data as a string (containing digits) than as a number. – Jonathan Leffler Oct 07 '19 at 19:24
  • 1
    I can verify your results with my MSVC where `long` is 32 bits (the guaranteed minimum), giving the spurious result, and replacing `long num1` with `long long num1` and `%ld` with `%lld` which gives the correct result. – Weather Vane Oct 07 '19 at 19:25
  • @JonathanLeffler in UK the ISBN check "digit" can be `'X'` because the checksum is modulo `11` but I think this is the **EAN** checksum calculated here, not **ISBN** but I agree a string is better. – Weather Vane Oct 07 '19 at 19:27
  • The ISBN rules are the same outside the UK and inside the UK, @WeatherVane, at least for the older 10-digit (including check character) version — where X is also used, as you say. I'm not sure how the newer 13-digit 'numbers' work, and whether X is still used — I've not gone off to study that part of Wikipedia yet. – Jonathan Leffler Oct 07 '19 at 19:29
  • @WeatherVane Thank you I tried long long int and it ended up working – Alex bob Oct 09 '19 at 07:36

0 Answers0