Keith Marshall
keith****@users*****
Fri Apr 20 21:39:09 JST 2018
ForkOn 20/04/18 07:45, Ray Satiro wrote:
> On 4/17/2018 8:11 AM, Keith Marshall wrote:
>> On 17/04/18 11:38, Keith Marshall wrote:
>>> A possibly more robust implementation of _fseeki64(), suitable for
>>> use on any Windows version prior to Vista, may be:
>>>
>>> __CRT_ALIAS __int64 _fseeki64
>>> ( FILE *__file, __int64 __pos, int __whence )
>>> {
>>> fseek( __file, 0, SEEK_CUR );
>>> return _lseeki64( _fileno(__file), __pos, __whence );
>>> }
>>
>> Actually, not quite correct; the return type and value should *not*
>> match those of _lseeki64(). It should rather be:
>>
>> __CRT_ALIAS int _fseeki64
>> ( FILE *__file, __int64 __pos, int __whence )
>> {
>> return (fseek( __file, 0, SEEK_CUR ) == 0)
>> ? (_lseeki64( _fileno(__file), __pos, __whence ) == -1LL)
>> ? -1
>> : 0
>> : -1;
>> }
>>
>> and fseeko64() could simply become:
>>
>> __CRT_ALIAS int fseeko64
>> ( FILE *__file, __off64_t __pos, int __whence )
>> { return _fseeki64( __file, (__int64)__pos, __whence ); }
>
> Thanks Keith. How do you know that fseek will invalidate iob though,
> is that guaranteed? I do not see it in the documentation.
It has to be so, otherwise all sorts of random, unpredictable behaviour
could ensue, following any fseek() call. Besides, I adapted the set of
actions you described, into a formal test case, to verify on both WinXP
and Win7 virtual machines, that it DTRT.
However, I then began to wonder if "fseek (__file, 0, SEEK_CUR)" would
continue to DTRT, beyond the 2GB file size boundary, so I went one step
further, and created a 4GB file with predictable and verifiable content
to check this hypothesis. It turns out that my concern was justified:
fseek() fails, even for no change in position, when the starting point
is beyond LONG_MAX! To make it work, we have to use:–
int _fseeki64 (FILE *file, __int64 offset, int whence)
{
fpos_t p;
return ((fgetpos (file, &p) == 0) && (fsetpos (file, &p) == 0))
? ((_lseeki64 (_fileno (file), offset, whence) == -1LL) ? -1 : 0)
: -1;
}
This now DTRT, on both WinXP and Win7, either side of the 2GB file size
boundary. Also note that I've now chosen to drop the __CRT_ALIAS; that
implies an inline implementation within <stdio.h>, but _lseeki64 is not
declared there ... it is correctly declared in <io.h>, and to make it
available for an inline _fseeki64() implementation would pollute the
<stdio.h> namespace.
> Also, I am not sure why you did not get my e-mail to the mailing
> list. I am BCCing you on this e-mail so you should receive two copies
> of it. If not maybe there is some issue with the list that needs to
> be addressed. Let me know if I can help.
Well, I didn't get two copies, but I have the nodups option set on my
list subscription; now, I don't know if the copy I received came via the
list, or as a bcc, but I suspect the latter. BTW, you should not bcc
anyone on mail you send to any mailing list; mailman has on option which
should reject mail which specifies bcc'd recipients, so I'm quite
surprised that this message you've bcc'd to me actually made it into the
list archive.
BTW, I also note that you've set the hidden option on your list
subscription. That doesn't prevent me, as list administrator, from
seeing your address, and since the list is configured to allow only
administrators to see subscriber addresses, the hidden option is
redundant anyway. FWIW, you are the only subscriber to have set that
option; this may, or may not, have something to do with my failure to
receive your original post.
--
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : https://lists.osdn.me/mailman/archives/mingw-users/attachments/20180420/d804316b/attachment.pgp