Edited VFSFileImpl::read to use both read/fread

[P-R-O-C-H-Y]

Summary

Edited VFSFileImpl::read to use read function instead of read when read size is bigger than 128 bytes.
There is check to FILEs internal buffer if there are some bytes read left. If yes, clear the buffer and set the pointer to deleted data, so it will read them again with read function.

Impact

Higher read speeds on SD cards when reading more than 128bytes.

Related links

[s-hadinger]

This commit breaks reading files in Tasmota.

Scenario 1:

• open file
• read 128 bytes
• read 128 bytes
• close

f=open("robotocondensed_latin1.tapp")
s1=f.readbytes(128)
s2=f.readbytes(128)
f.close()
print(s1)
print(s2)

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('6C6174696E312873697A6529600A0A696D706F727420726F626F746F636F6E64...')

Scenario 2:

• open file
• read 128 bytes
• read 256 bytes
• close

f=open("robotocondensed_latin1.tapp")
s1=f.readbytes(128)
s2=f.readbytes(256)
f.close()
print(size(s1))
print(s1)
print(s2)

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('1300207C9004822410900F1004C170003804E626822258748689F0180000200C...')

In scenario 2, the second read of 256 bytes following the first read of 128 bytes provides wrong content
Edit: the second read for 256 bytes actually starts at offset 0x1000 in the file, instead of offset 0x80. I do see a crash later as a hint of corrupt memory.

I have some questions:

• __fpending(_f); is normally for the output buffer, not the input buffer. Am I missing something?
• lseek(fileno(_f),(-128+bytesinbuf),SEEK_CUR); why is the file seeked 128 bytes ahead of bytesinbuf? Are we even sure that bytesinbuf is always greater than 128? If not the substraction is invalid and yields to an overflow.