Web lists-archives.com

Re: [Mingw-users] Missing pread, pwrite




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/03/17 12:34, Antonio Diaz Diaz wrote:
> The implementation I sent is indeed inadequate for general use. I was 
> under the false impression that ReadFile/WriteFile were equivalent to 
> pread/pwrite, but I have just been told that they are not. They modify 
> the file position.

Thanks.  Without even looking at the code, I feared as much.  On that 
basis, they would not be acceptable for incorporation into MinGW, and 
with that in mind, (that I will not use it), I did take a peek at your 
code; it turns out to be equivalent to, (omitting error handling):

ssize_t pread (int fd, void *buf, size_t count, __int64 offset)
{
  _lseeki64 (fd, offset, SEEK_SET);
  return read (fd, buf, count);
}

ssize_t pwrite (int fd, const void *buf, size_t count, __int64 offset)
{
  _lseeki64 (fd, offset, SEEK_SET);
  return write (fd, buf, count);
}

with no attempt whatsoever to either preserve, or to restore the file 
pointer; (indeed, since these don't expose the ugliness of Microsoft's 
lower level ReadFile() and WriteFile() APIs, I would favour such code 
over that which you proposed).

> They happen to work in plzip because the file is opened just once and
> calls to pread/pwrite are never mixed with calls to read/write.

Sure, if you only ever use pread() and pwrite() to perform your data 
I/O, you don't need to be concerned with any possible (bad) interactions 
with read() and write(); OTOH, any worthwhile library implementation for 
MinGW *would* need to show such concern.  However, from an outsider's 
perspective, even in the context of your plzip usage, I might tend to be 
concerned by the total absence of any thread synchronization protocol, 
in your proposed code.

All that said, and while I will not adopt your proposed implementation 
as it stands, I do believe that an acceptable implementation could be 
developed; it would be non-trivial, requiring creat(), open(), read(), 
write(), dup(), dup2(), close(), and probably a few other existing calls 
to be wrapped in some thread synchronization protocol, together with 
similarly wrapped implementations for pread() and pwrite().  It would 
(necessarily) be subject to usage restrictions, (unlike a truly POSIX 
conforming implementation), and should be governed by an opt-in feature 
test macro; as such, I don't know how much interest that would engender 
among MinGW users, and I will not pursue it further, without a formal 
feature request ticket on which its development may be discussed.

- -- 
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)

iQIcBAEBAgAGBQJY1pOZAAoJEMCtNsY0flo/dcgQALNHUMe9YZ5T7cfrr18UWw96
/0lNwuTxOZXJlNF+AQOomNsWM226ZblQD1VnSvKaruyCjsOC40jbScfV/GU+ocpX
XGjHOscKRGGRSCbxgUZZ7113L2T5dGgnVRyKo4de5TVz/ntWIwhX5XnOSdLqD9Rr
f0mvs31s8W5C2o46rWrH9hs8e6uozhstIm5/Rar8SMmKYtuVw0HaIJ0tVAzElZe2
oTJaqjtEEqAOGKIq9XorAnSd9+YZiOLmdtxHPyFz04M4lybDrOhQmX4TYhhewQwt
h1jG1Nf74OmbtIHeDYB4Ib4ZX/94S6FvrgngSyN7ly7z5S7rE3bSVYAYoGX7DQ06
mmFYvhK2ioenxiXc/hyrbTucfWGMocp6gzGuArfUdZqdQGzutbDjxiKzaljUTIiI
mB/ewpcbVnEcXtapFRyrc/4g5i3yjvHt0FitkT4OojG1ZqyD6f72pDUUMP7t75Ql
zMmTrCtLtMZOcIDOVmAW1wdrMIx3b6A2KGMwEExUa06relYWDWXWS44Xz9kiLJ9U
WbBmTc/afR91KtfOAUrD9YOsXedVYNbiMk5jeZDrTnuPzwzsMskUKjttEyDLlBkc
QOSz1L17MoLV05opn8606/ztIzBdLDnXUxajolTW2GF/VnBh0hkkMc+69/NPlncY
quZeEREqcy582Ltkm/Ri
=MXw/
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe