Web lists-archives.com

Re: [Mingw-users] Missing pread, pwrite

> From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
> Date: Sat, 25 Mar 2017 15:58:17 +0000
> 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).

Why is that better than the original code proposal?  That one at least
didn't suffer from the race condition between the lseek and the
following read/write call.

And where is the evidence that ReadFile/WriteFile indeed modify the
file position?  The MSDN docs says that the offset is updated, but
says nothing about the file pointer.

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