Keith Marshall
keith****@users*****
Tue Apr 17 23:38:56 JST 2018
Fork-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17/04/18 11:38, Keith Marshall wrote:
>> Assume FILE *f opened rb with contents "abcdef":
>>
>> printf("%c\n", fgetc(f)); printf("%c\n", fgetc(f));
>> _lseeki64(_fileno( f ), 4, SEEK_SET); printf("%c\n", fgetc(f));
>>
>> The third fgetc call is going to get the third character 'c' and
>> not the fifth 'e'.
>
> Indeed, yes; the stream pointer has been relocated to the 'e', but
> the __iob pointers still refer to stale data, within the __iob
> buffer, and thus indicate that next available character is the
> 'c'.
Hmm. Some playing with this reveals another anomaly, which may arise
when using _lseeki64() to emulate _fseeki64(): if we call _telli64(),
before reading any input from the stream, then the reported position
is zero, but _ftell() reports this position as *one*. I suspect the
same disparity may arise, between _fseeki64() and _lseeki64().
- --
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAEBAgAGBQJa1gcAAAoJEMCtNsY0flo//GoP/As578A7uoC8ufvOvVWKVB7k
SswcXxkroI/yVrOolIHMylpXcYBGwrbC9qW0Sx1UzOXfFdsaS0zG55UpkyRMRqEO
dWfAzucazzKGH5HeuvJLRCOmkMnclRPhIKQ6BP8d5i9rjkmxKWLSmKF6W+pjEpWL
81hVAhIkvPITRrH3TLcvoonersiwprNrCLukIZx0YUFqA3+zv0bSiAKXie2jPuRF
TeJBB2L5b1FmJleYpjDfvzxRrbmirr2VoaUpoEzUcjryiPLYo6P7r8yULLubbSy9
ugGNUElHB1WPdLZcPtaS4Zn4vB5mwXisAJD5yHTUg5PoDREqi10rFPmFnmTOk8fk
0beBiIewLXqHE13RrKHHpuVg5ah1H+hnpMtD0PJHtiYgS7f0Xnu1thAsvkdGypfb
NgDBccibDHeetyR4blAjI7J/Suqs4iDRD8+RPc39Uj1ETYmcPuymblgwwZmCIfeR
i2Cv2lJdfPnemgr08lBRmp9FxbGhjRCP29XMkcqy3q73GQKLfX9gMWBhRwLDQwr+
iHZFsMH+m+GQfC7pOhJfhek98fyM2PyKxXT2hHCB7hs5vCarlCuDg9WYeuFWQqYh
UdPtAZ+DrKlTClWe3ju0pdSnhjhMz4amBKSd0Aa3/7WHAqWW/kzdFZXdqQ2dfjGU
VeEsTtzBMDZ51ITHtVRC
=Ruxt
-----END PGP SIGNATURE-----