fgets() reads, at most your 10000 bytes, or until it hits a newline '\n' or EOF - you might want to call it in a loop if each number is on a newline in your file.

Also, your integer array should store integers and your fgets() is reading a string, so you need to convert the characters that represent your integer in the text file, to an integer data type (lookup the atoi() function).

What I'm thinking is something like this - you might need to play around with it.

Code (Text):

char *buffer;
int BUF_SIZ = 10; // size of a line in your file, 10 digits enough for your ints?
int array[10000];
int i = 0;
while(fgets(buffer, BUF_SIZ, file) != EOF && i < 10000) // while file not EOF and i is less than max array bound
{
int number = atoi(buffer); // convert the number you just read from string to int
array[i] = number; // store the number in the next free array slot
i++; // increment the array index
}

If you store your numbers in binary, you could use fread() to read the whole file into an int array, but I think you are storing them as ASCII text (ie. readable).

Staff: Mentor

Also, your integer array should store integers and your fgets() is reading a string, so you need to convert the characters that represent your integer in the text file, to an integer data type (lookup the atoi() function).

Surely it would be easier to read the file using fscanf() which does the character-to-integer conversion for you, with a suitable format descriptor.

fgets() reads, at most your 10000 bytes, or until it hits a newline '\n' or EOF - you might want to call it in a loop if each number is on a newline in your file.

Also, your integer array should store integers and your fgets() is reading a string, so you need to convert the characters that represent your integer in the text file, to an integer data type (lookup the atoi() function).

No. Each iteration through the loop you reset i = 0, store the read value into a[0], and then increment i. In the next iteration (assuming EOF hasn't been reached), i is again set to 0, the new value of buffer is stored at a[0], overwriting the previously stored value, and then i is incremented again. There's an obvious fix for this.

No. Each iteration through the loop you reset i = 0, store the read value into a[0], and then increment i. In the next iteration (assuming EOF hasn't been reached), i is again set to 0, the new value of buffer is stored at a[0], overwriting the previously stored value, and then i is incremented again. There's an obvious fix for this.

Staff: Mentor

In the code you show in post #6, if the data in the file happens to be in sorted order, from small to large, the final value of k will be 0.

For example, suppose the numbers in a much smaller version of your file are 1, 2, 3, 4, 5, and 6.

The outer loop first looks at a[0] (== 1) and compares it to the subsequent values in the array, all of which are larger, so the comparison a > a[j] will be false. This means that k does not get incremented.

The outer loop then looks at a[1] (== 2) can compares it to subsequent values in the array, so again, the comparison a > a[j] will be false, and k does not get incremented.

The same thing keeps happening for this scenario, resulting in a value of k that is still 0.

Staff: Mentor

You don't need long long int (64 bits). For 100,000 numbers long int (most likely 32 bits) is more than sufficient, since it can deal with numbers up to around 2,000,000,000+ (signed) or 4,000,000,000+ (unsigned).

Your compiler must be pretty old - about 1996, many compilers switched the size of an int from 16 bits to 32 bits. Prior to that change, short int and int were 16 bits and long int was 32 bits. After the change, short int was still 16 bits, but int and long int were the same at 32 bits.