fscanf() behavior on MIPS processor

[gb]

Hi,

I have a small program which opens a file (Whose content is a mac
address in the form xx:xx:xx:xx:xx:xx) and uses fscanf() to get
individual bytes into an array which is defined as "unsigned char
macaddress[6]". The strange thing is that it prints zeroes on MIPS
processor where as it works correctly on x86 systems. Appreciate if
some body could help to understand the fscanf() behavior.

Here is the code I am using:

#include <stdio.h>

main()
{
FILE *fp;
unsigned char macaddress[6];
char buf[50];

fp = fopen("/tmp/macaddress", "r" );
if (fp == NULL ) {
printf("Couldn't open the file \n");
return -1;
}
fscanf(buf,"%x:%x:%x:%x:%x:%x",
&macaddress[0],&macaddress[1],&macaddress[2],&macaddress[3],&macaddress[4],&macaddress[5]);
printf("MAC address: %x:%x:%x:%x:%x:%x\n",macaddress[0],
macaddress[1], macaddress[2], macaddress[3], macaddress[4],
macaddress[5]);
fclose(fp);
}

Thanks in Advance
--gb

 

[Irrwahn Grausewitz]

Here is the code I am using:

#include <stdio.h>

main()
{
FILE *fp;
unsigned char macaddress[6];
char buf[50];

fp = fopen("/tmp/macaddress", "r" );
if (fp == NULL ) {
printf("Couldn't open the file \n");
return -1;
}
fscanf(buf,"%x:%x:%x:%x:%x:%x",
&macaddress[0],&macaddress[1],&macaddress[2],&macaddress[3],&macaddress[4],&macaddress[5]);
printf("MAC address: %x:%x:%x:%x:%x:%x\n",macaddress[0],
macaddress[1], macaddress[2], macaddress[3], macaddress[4],
macaddress[5]);
fclose(fp);
}

Besides some other minor issues with your code (e.g. implicit int;
unportable return code; failure to check return value of fscanf),
you most certainly want to reread your library documentation
for proper invocation of the fscanf function. ;-)

Thanks in Advance

HTH

 

[Irrwahn Grausewitz]

Besides some other minor issues with your code (e.g. implicit int;
unportable return code; failure to check return value of fscanf),

<snip>

s/minor/major/

 

[Lawrence Kirby]

Hi,

I have a small program which opens a file (Whose content is a mac
address in the form xx:xx:xx:xx:xx:xx) and uses fscanf() to get
individual bytes into an array which is defined as "unsigned char
macaddress[6]". The strange thing is that it prints zeroes on MIPS
processor where as it works correctly on x86 systems. Appreciate if
some body could help to understand the fscanf() behavior.

Your code invokes undefined behaviour so anything can happen and it is
reasonable for different things to happen on different implementations.

Here is the code I am using:

#include <stdio.h>

main()

Make that

int main(void)

for good stype and to be compatible with current definitions of C.

{
FILE *fp;
unsigned char macaddress[6];
char buf[50];

fp = fopen("/tmp/macaddress", "r" );
if (fp == NULL ) {
printf("Couldn't open the file \n");
return -1;

The standard defined exit() values (and alse return values from main())
are 0, EXIT_SUCCESS and EXIT_FAILURE. The last 2 are macrosd defined in

}
fscanf(buf,"%x:%x:%x:%x:%x:%x",
&macaddress[0],&macaddress[1],&macaddress[2],&macaddress[3],&macaddress[4],&macaddress[5]);

The %x fcanf() format specifier requires a corresponding argument of
unsigned * (i.e. it writes to an unsigned int object) but you're passing
it a pointer to unsigned char.

In C99 you can fix this by using %hhx instead of %x. If you want to stay
compatible with C90 you could write the converted values to an array of
unsigned int, then copy then to the array of unsigned char afterwards.

printf("MAC address: %x:%x:%x:%x:%x:%x\n",macaddress[0],
macaddress[1], macaddress[2], macaddress[3], macaddress[4],
macaddress[5]);

This is OK, because the daefault argument promotions will convery unsigned
char arguments to int (or in rare circonstances unsigned int) which is OK
for %x. There are no such conversions pointers, nor could there be because
the pointer has to have the appropriate type for the object being pointed
at.

fclose(fp);

return 0;

}

Lawrence

 

[gb]

Hi,

Thanks a lot for your comments. I agree that my code was not very
portable and elegant as it was just a test program. Appreciate your
useful suggestions.

I was able to fix the problem by using "%hhx" instead of "%x".

Thanks once again
--gb

 

[Irrwahn Grausewitz]

I was able to fix the problem by using "%hhx" instead of "%x".

<snip>

The hh length modifier was added in C99, you're indeed lucky if you
have a C99 conforming library at hand. If portability is important
for your project, you might want to think about a workaround, e.g.
fetch input in terms of int and cast to unsigned char.

Best regards