Bug 695842 - pread/pwrite not available under MINGW
Summary: pread/pwrite not available under MINGW
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-19 16:31 UTC by Dan Sebald
Modified: 2015-02-22 23:43 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Sebald 2015-02-19 16:31:05 UTC
From one of the Octave developers/testers:

"The latest gp_unifs.cpp uses pread/pwrite that are not available in mingw, and so need replacement functions defined."
Comment 1 Ken Sharp 2015-02-20 00:08:16 UTC
Can we please stop making the component here 'PDF writer', problems with missing OS functionality is *NOT* anything to do with the pdfwrite device. Putting the component as 'PDF Writer' means they get assigned to me, and fixing unsupported operating systems is *not* my area of expertise.
Comment 2 Chris Liddell (chrisl) 2015-02-20 01:37:56 UTC
I've dealt with all of these, so far, so......
Comment 3 Chris Liddell (chrisl) 2015-02-20 07:37:52 UTC
It should work now with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5135b9cd


As noted, the lack of pread/pwrite means no multi-thread rendering - but, IIRC, we disable that for MINGW anyway, so....
Comment 4 Dan Sebald 2015-02-22 14:00:30 UTC
No feedback either way so far, but let's assume this is correct.  The substitute for pread/pwrite with the various tests of results looks thorough and correct to me.  The additions to the configure scripts makes sense as well.  Multithreadedness isn't required for our application...  Thank you.
Comment 5 Hin-Tak Leung 2015-02-22 15:35:28 UTC
pread/pwrite is posix 2001 so I assume cygwin provides it; and AFAIK multi-threaded rendering works for the proper windows code paths (with MS VC). So it would appear that mingw build is inferior to both cygwin and MSVC builds. There is probably some incentive to make mingw build use the MSVC code path instead of the cygwin one?

Support for borland and watcom was removed(?) a couple of years ago so, windows build == MSVC build these days.
Comment 6 Dan Sebald 2015-02-22 17:29:50 UTC
Oh, one thing to ponder, I guess, although I'm not so sure how often the situation will arise, and I don't know the answer.  In the following:

+    uint c;
+    int64_t os, curroff = gp_ftell_64(f);
+    if (curroff < 0) return curroff;
+    
+    os = gp_fseek_64(f, offset, 0);
+    if (os < 0) return os;
+    
+    c = fread(buf, 1, count, f);
+    if (c < 0) return c;
+    
+    os = gp_fseek_64(f, curroff, 0);
+    if (os < 0) return os;

what if curroff is valid (success on the ftell), the first seek is valid and then there is a failure on the fread()?  Rather than return right away, should an attempt be made to place the file pointer back to curroff?  I can't imagine how that scenario would arise (another file altering the file contents right before the read is done, perhaps?).
Comment 7 Chris Liddell (chrisl) 2015-02-22 23:43:27 UTC
(In reply to Dan Sebald from comment #6)
> Oh, one thing to ponder, I guess, although I'm not so sure how often the
> situation will arise, and I don't know the answer.  In the following:
> 
> +    uint c;
> +    int64_t os, curroff = gp_ftell_64(f);
> +    if (curroff < 0) return curroff;
> +    
> +    os = gp_fseek_64(f, offset, 0);
> +    if (os < 0) return os;
> +    
> +    c = fread(buf, 1, count, f);
> +    if (c < 0) return c;
> +    
> +    os = gp_fseek_64(f, curroff, 0);
> +    if (os < 0) return os;
> 
> what if curroff is valid (success on the ftell), the first seek is valid and
> then there is a failure on the fread()?  Rather than return right away,
> should an attempt be made to place the file pointer back to curroff?  I
> can't imagine how that scenario would arise (another file altering the file
> contents right before the read is done, perhaps?).

As the pread/pwrite code was added specifically to support the clist, it really doesn't matter. And what worries me is adding extra complexity in a place that can be quite critical to performance.

And I also wanted to ensure that errno was set by the fread() when we return the error, rather than by fseek().

I guess the worry is that it might start being used for things other than the clist, but I can't really imagine what else would need that kind of functionality.

I'll give it some thought.