4

I'm starting to learn UPC, and I have the following piece of code to read a file:

upc_file_t *fileIn;
int n;
fileIn = upc_all_fopen("input_small", UPC_RDONLY | UPC_INDIVIDUAL_FP , 0, NULL);
upc_all_fread_local(fileIn, &n, sizeof(int), 1, UPC_IN_ALLSYNC | UPC_OUT_ALLSYNC);

upc_barrier;
printf("%d\n", n);

upc_all_fclose(fileIn);

However, the output (value of n) is always 808651319, which means something is wrong, and I can't find what is it. The first line of the file I'm giving as input is '7', so the result of the printf should be 7...

Any idea why this happens?

Thanks in advance!

dx_mrt
  • 707
  • 7
  • 13

1 Answers1

4

UPC Parallel I/O library performs unformatted (binary) input/output, not formatted one like what you get with (f)printf(3)/(f)scanf(3) from the standard C library. Parallel I/O cannot handle text files because of their intrinsic properties like variable-length records.

upc_all_fread_local(fileIn, &n, sizeof(int), 1, UPC_IN_ALLSYNC | UPC_OUT_ALLSYNC)

behaves like the following call to the standard C library function for unformatted read from a file:

fread(&n, sizeof(int), 1, fh)

You are just reading 1 element of sizeof(int) bytes from the file (4 bytes on most platforms) into the address of n. The number you got 808651319 in hexadecimal is 0x30330A37. On little endian systems like x86/x64 this is stored in memory and on disk as 0x37 0x0A 0x33 0x30 (reversed byte order). These are the ASCII codes of the first 4 bytes of the string 7\n30 (\n or LF is the line feed/new line symbol) so I'd guess your input_small file looked like:

7
30...
...

You should prepare your input data in binary format using fwrite(3) instead of using (f)printf(3) or your text editor of choice.

Hristo Iliev
  • 72,659
  • 12
  • 135
  • 186