Unusual Behaviour while passing an array to a function...

Question

#include <stdio.h>
#define SIZE 5

void func(int*);
int main(void)
{
  int i, arr[SIZE];
  for(i=0; i<SIZE; i++)
    {
          printf("Enter the element arr[%d]: ", i);
          scanf("%d", &arr[i]);
        }//End of for loop

  func(arr);
  printf("The modified array is : ");

  for(i=0; i<SIZE; i++)
    printf("%d ", arr[i]);

  return 0;

}

  void func(int a[])
 {
   int i;

   for(i=0; i<SIZE; i++)
    a[i] = a[i]*a[i];
 }

Output :::

While I'm entering integer elements the output is OK.But as I entered a float value like 1.5, it didn't ask for other elements and the O/P is as shown in the figure.I think it should implicitly typecast 1.5 to 1 but it didn't happen..can u plz tell why this happened ? All the info about the compiler is shown in the figure.

Answer 1

Problem with buffer - I think the remaining part (.5) remains on the buffer. use flushall(); after your scanf("%d..

Answer 2

When you scanf("%d") a value like 1.5 the scanning will stop at the decimal point and return 1.

The next time you call scanf, the pointer will still point to the decimal point and your scan will return immediately because there are no digits there to scan.

You should be checking the return value from scanf - it gives you the number of items successfully scanned which will be 1 initially for the 1 before the decimal point, and 0 from then on.

As an aside, scanf stands for "scan formatted" and I'll guarantee you won't find anything more unformatted than user input.

Investigate looking into fgets for line input. Here's a copy of a function I often use for such purposes:

#include <stdio.h>
#include <string.h>

#define OK       0
#define NO_INPUT 1
#define TOO_LONG 2
static int getLine (char *prmpt, char *buff, size_t sz) {
    int ch, extra;

    // Get line with buffer overrun protection.
    if (prmpt != NULL) {
        printf ("%s", prmpt);
        fflush (stdout);
    }
    if (fgets (buff, sz, stdin) == NULL)
        return NO_INPUT;

    // If it was too long, there'll be no newline. In that case, we flush
    // to end of line so that excess doesn't affect the next call.
    if (buff[strlen(buff)-1] != '\n') {
        extra = 0;
        while (((ch = getchar()) != '\n') && (ch != EOF))
            extra = 1;
        return (extra == 1) ? TOO_LONG : OK;
    }

    // Otherwise remove newline and give string back to caller.
    buff[strlen(buff)-1] = '\0';
    return OK;
}

 

// Test program for getLine().

int main (void) {
    int rc;
    char buff[10];

    rc = getLine ("Enter string> ", buff, sizeof(buff));
    if (rc == NO_INPUT) {
        // Extra NL since my system doesn't output that on EOF.
        printf ("\nNo input\n");
        return 1;
    }

    if (rc == TOO_LONG) {
        printf ("Input too long [%s]\n", buff);
        return 1;
    }

    printf ("OK [%s]\n", buff);

    return 0;
}

Once you get a line in with that function, you can sscanf it to your heart's content, handling errors much easier.

Answer 3

What's happening is that scanf stops reading an integer when it sees the '.' character, and leaves it in the input buffer. Then subsequent calls to scanf fail because the next character is '.' and not something parseable as an integer.

How do you fix this? The first step is to forget you ever heard of scanf and always use fgets to read whole lines of input, then process them after you read them into a string buffer. You can use sscanf for this purpose, but a robust function like strtol would be a lot better.