[gs-devel] Problems with stdin and return code -101
Sheri_Steeves at peernet.com
Fri Feb 6 14:28:41 PST 2009
That's just a misnomer in the name of the function I use to return the file handle from the outside class - I am using a C RTL file handle.
In the end, I decided to simply copy the file to a temp file with a location that is readable (narrow) by Ghostscript and process the copied file. This gives me only one single code path for PDF, PS and EPS to maintain and is based on your recommendation that it was faster to simply copy the PDF than to stream it to Ghostscript using stdin to have ghostscript make a temp copy of the file anyway.
Thanks for all the help from both you and Ken. It was very much appreciated.
PEERNET Technical Support
Have questions? Find your answers in our new forums!
Toll Free: 1-800-883-7980
613-224-6894 ext 230
From: Russell Lang [mailto:gsview at ghostgum.com.au]
Sent: Friday, February 06, 2009 5:30 AM
To: gs-devel at ghostscript.com; Sheri Steeves
Subject: RE: [gs-devel] Problems with stdin and return code -101
Your code used
fh = pJobProcessor->GetGSConverter()->GetFileHandle();
nRead = _read( fh, buf, len ) ;
Note that there are two types of file handles. There is the Windows file handle (type HANDLE) and the C RTL file handle (type int).
The C function _read requires the C file handle. If you give it the Windows file handle it will almost certainly fail in the way you describe. That is, _read will return -1 for error, which will cause ghostscript to exit.
If you want to associate a Windows file handle with a C file handle, then you use something like
fd = _open_osfhandle((long)hfile, 0);
if (fd == -1)
I tried to find a way to set the code page on a per process or per thread basis, but it looks Windows can't do this. My thought was that if you could force GS to use the UTF-8 code page, then you could easily write a wrapper to map a Unicode command line into UTF-8.
On 6 Feb 2009 at 8:47, Ken Sharp wrote:
> Hi Sheri,
> At 12:14 05/02/2009 -0500, Sheri Steeves wrote:
> >Thanks for quick response.
> I see you've been talking to Russell too ;-)
> >to a log file, and that's where I got the error message "failed to open
> >the file", and the lRet from gs_init_with_args returned -101. Stupid of
> >me to assume, I should have checked the error codes.
> Not a problem, but I needed to clear up my own confusion :-)
> >I had traced my stdin callback, I did have a valid handle and I was
> >reading data. I did this before posting to the list! I also get a valid
> >output file for ps and PDF (which was weird... - just lucky?).
> No, this sounds correct. It seems like you fed the PostScript file to GS
> and it created output files, then when you ceased sending bytes it closed
> GS using the quit operator (which is normal) and returned the -101 error
> code so that you know why it terminated.
> The puzzle is the 'failed to open file' error message. I've had a scan
> through the source code and I can't find an error message which matches
> that. Could you try again and post the full text please ?
> >IF gs_init_args returns -101 (exit) for error or end of file, I can put
> >some sanity code in my stdin so that when I read less bytes than
> >requested, I know I'm at the EOF and the -101 is not "really" and error.
> Well -101 means the quit operator was executed, this is documented
> somewhere.. Ah, in /doc/API.htm, section 3.11 Return Codes:
> e_Quit "quit" has been executed. This is not an error. gsapi_exit()
> must be called next.
> < 0 Error
> <= -100 Fatal error. gsapi_exit() must be called next.
> PostScript errors lie between -1 and (nominally) -99 though actually only
> about 39 are used. -100 is a fatal error, and includes use of the quit
> operator in the context of a real PostScript error.
> So you can special case error return -101 as an end of input safely.
> gs-devel mailing list
> gs-devel at ghostscript.com
Russell Lang gsview at ghostgum.com.au
Ghostgum Software Pty Ltd http://www.ghostgum.com.au/
More information about the gs-devel