pdfwrite - Fix indeterminism with QL shading tests

When creating a new colour space to put in a PDF file we perform various
tests to see if its a space we have already written, to prevent writing
duplicate spaces (we perform similar tests for most resources).

In some cases, when we write the resource to a file, we create an MD5
hash and compare those to see if the resources are the same. In the
case of colour spaces, however, they are retained in memory and so we
use a different method. We 'serialise' the colour space. This is not the
same as writing it to the PDF file, and its a graphics library thing not
a pdfwrite function. Basically this writes out the content of the
various C structures. The stream we use is an in-memory stream.

Unfortunately, for Separation colour spaces, there was a fault in the
function which writes the colour space name, and it was writing out
the bytes forming the address of the name instead of the actual string.

This could, very rarely, mean that we would mis-identify a new colour
space as being the same as an old colour space, and so would reuse the
old space instead of creating a new one.

I've checked the DeviceN code and it does not suffer the same problem.

1 files changed, 1 insertions, 1 deletions

diff --git a/base/gscsepr.c b/base/gscsepr.c
index 3f10ba249..abde85902 100644
--- a/base/gscsepr.c
+++ b/base/gscsepr.c
@@ -547,7 +547,7 @@ gx_serialize_Separation(const gs_color_space * pcs, stream * s)
 
     if (code < 0)
         return code;
-    code = sputs(s, (const byte *)&p->sep_name, strlen(p->sep_name) + 1, &n);
+    code = sputs(s, (const byte *)p->sep_name, strlen(p->sep_name) + 1, &n);
     if (code < 0)
         return code;
     code = cs_serialize(pcs->base_space, s);