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.

I've dealt with all of these, so far, so......

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

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.

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.

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

(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.