Web lists-archives.com

Re: [Mingw-users] Missing pread, pwrite

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.

- -- 

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
Version: GnuPG v2.0.20 (GNU/Linux)


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

This list observes the Etiquette found at 
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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe