devkitarm: file read data corruption

[bgK]

While investigating this downstream bug, I've noticed an issue with a patch devkitPro does to newlib's fread function: https://bugs.scummvm.org/ticket/11342

The program does the following calls to trigger data corruption:

    char *buffer = (char *)malloc(20*1024);

    // Open a file for reading with buffered IO
    FILE *f = fopen("sdmc:/ScummVM/The Dig/DIG.LA1", "r");

    // Go somewhere in the file, unimportant
    fseek(f, 23800663, SEEK_SET);
    // Initialize the stdio read buffer
    fread(buffer, 1, 1, f);
    // Make a large read that enters devkitPro's fread patched code path.
    // After this, the stdio read buffer is out of sync with the stream position.
    fread(buffer, 1, 10096, f);
    // Seek back a bit in the file. The target seek position is inside the buffer from
    // stdio's perspective (but actually is not as the buffer is out of sync with the actual
    // stream position).
    fseek(f, 23810752, SEEK_SET);
    // Make a small read. The data is fetched from the stdio buffer. It is inconsistent with what is actually in the file.
    fread(buffer, 1, 4, f);

    fclose(f);

I suggest reverting this patch: https://github.com/devkitPro/newlib/blob/a7caafc1971a52eaeb86eed0d59179bcb42e1ddc/newlib/libc/stdio/fread.c#L231

[fgsfdsfgs]

Can confirm I've encountered this bug on Switch, especially when reading large files like PK3 archives in Quake 3.

[mtheall]

I have tested with the fread.c file reverted to original newlib code and this sequence of events still reads the wrong data.

False alarm

[WinterMute]

this is fixed with devkitARM r54 and devkitA64 r15