🚀 go-pugleaf

Re <9209110403.AA02109@cookie-crisp>
<1992Sep10.172611.25400@dcs.warwick.ac.uk>:

> I have just discovered a problem with Ghostscript 2.5.  It was triggered
> by the code generated by psraster.  In this it reclaims VM by performing a
> 'restore save' in the procedure used to decode the image data.  The actual
> code is of the following form:
> 
>     [...] {restore save GetImageRow} save 6 1 roll image
>     [...]
>     restore
> 
> This works fine on the printers, but causes Ghostscript to complain:
> 
>     Error: /invalidrestore in --restore--
>     Operand stack:
> 	-savetype-

I believe the problem arises because the 'image' operator allocates
some buffer storage in the same memory pool managed by save and
restore, so the restore (correctly, from its point of view) can't
deallocate it while the image operation is in progress.

This is not a trivial problem to fix; the fix will have to wait for
release 2.6 or later.  Meanwhile, perhaps you could contact the
author of psraster to see if they can find a less heavy-handed way of
doing the job (e.g., reuse a single buffer inside the loop, and wrap
a single save/restore around the whole thing).

> The following is a small fragment that will also demonstrate the error:
> ) pop restore
> 
>     save 10 { (Hello, World!\n) print restore save } repeat restore

This is obviously incorrect code.  The procedure in the { } is
allocated within the scope of the first 'save'.  The first 'restore'
is invalid, because it is attempting to deallocate a procedure that
is still being executed.  Do printers execute this without
complaining??

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; voice 415-322-0103 ; fax 322-1734
    "Implementation is the sincerest form of flattery."    new--->^^^^^^^^^^^^