Thread: Getting weird results with isalpha

I wrote the following little test program to test out the isalpha function:

Code:

#include <stdio.h>
#include <ctype.h>
#include <stdlib.h>

main(int argc, char * argv[] )
{
   FILE * fp = fopen( argv[1], "r" );

   printf( "%d\n%d\n%d\n%d\n", isalpha(fgetc(fp)), isalpha(fgetc(fp)), isalpha(fgetc(fp)), isalpha(fgetc(fp)));

}

And ran it using this as my input text file:

Code:

a&b-

And got the following output:

Code:

0
1024
0
1024

According to what I've read, the isalpha function should produce non-zero values when given the letters 'a' and 'b', and it should produce zero when given '&' and '-'. This is the exact opposite of what the above code shows. Can someone tell me what's going on? Could there be a bug in this function? I'm using gcc to compile.

The order of evaluation of arguments in a function call is implementation defined. Make those calls to fgetc before the call to printf, or make a separate call to printf for each character read.

Most likely what happened here is that i = 0+1 = 1, then i = 1+1 = 2, then i = 2+1 =3, then i was used in all three cases.

That said, what you have here is worse: there is undefined behaviour, not just implementation defined behaviour, because you modify i more than once between sequence points (the previous sequence point was prior to the call of printf; the next sequence point is after all the arguments to printf have been evaluated).

Originally Posted by itsthemac

I think my problem was that I thought that the assignment statement evaluated to the value being assigned.

I don't have the C standard on hand to verify, but I think that it does.

Originally Posted by itsthemac

But I guess it evaluates to the value of the thing on the left of the assignment operator, after the assignment is done?

After assignment, the value of the object on the left of the assignment operator is the value being assigned.

Originally Posted by itsthemac

Therefore, in my post above it was taking the value of i (the thing on the left in each assignment statement) each time (after all three assignments had completed), not what was actually assigned to i each individual time.

As I stated, there is undefined behaviour. The output could also have been instead:

Code:

3
2
1

or:

Code:

0
0
0

or even:

Code:

Hello world!

or you could have experienced a crash, etc, and it would all be perfectly acceptable, i.e., not a compiler bug.