[tlbuild] Test failures for dvipdmfx on OpenBSD

[Masamichi Hosoda]

Hi all,

>> dvipdfmx non-deterministic behaviour
> 
> Devs from Japan investigated this;
> 
>   * It crashes at cmap_read.c L.579
>       MATCH_OP(tok1, "begincodespacerange")
>   * The crash occurs when the size of tok1->data is smaller
>     than strlen("begincodespacerange").
>   * When you use strncmp instead of memcmp in
>       #define MATCH_OP(t,n)
>     at cmap_read.c L.405, the crash will not happen.
>     OTOH, it may match longer strings such as "begincodespacerangeeeee".
>   * FYI, t1_load.c L.93 uses strncmp in a similar function MATCH_OP(t,n).

I would like to propose a patch
that can prevent the memory access violations
and does not allow long tokens like "begincodespacerangeeeee"
to match the string.

```
--- a/source/texk/dvipdfm-x/cmap_read.c
+++ b/source/texk/dvipdfm-x/cmap_read.c
@@ -401,8 +401,8 @@ do_cidchar (CMap *cmap, ifreader *input, int count)
 }
 
 
-#define MATCH_NAME(t,n) (PST_NAMETYPE((t))    && !memcmp(pst_data_ptr((t)),(n),strlen((n))))
-#define MATCH_OP(t,n)   (PST_UNKNOWNTYPE((t)) && !memcmp(pst_data_ptr((t)),(n),strlen((n))))
+#define MATCH_NAME(t,n) ((t) && PST_NAMETYPE((t))    && !strncmp(pst_data_ptr((t)),(n),strlen((n))+1))
+#define MATCH_OP(t,n)   ((t) && PST_UNKNOWNTYPE((t)) && !strncmp(pst_data_ptr((t)),(n),strlen((n))+1))
 
 static int
 do_cidsysteminfo (CMap *cmap, ifreader *input)
--- a/source/texk/dvipdfm-x/t1_load.c
+++ b/source/texk/dvipdfm-x/t1_load.c
@@ -89,8 +89,8 @@ t1_decrypt (unsigned short key,
 }
 /* T1CRYPT */
 
-#define MATCH_NAME(t,n) ((t) && PST_NAMETYPE((t))    && !strncmp(pst_data_ptr((t)),(n),strlen((n))))
-#define MATCH_OP(t,n)   ((t) && PST_UNKNOWNTYPE((t)) && !strncmp(pst_data_ptr((t)),(n),strlen((n))))
+#define MATCH_NAME(t,n) ((t) && PST_NAMETYPE((t))    && !strncmp(pst_data_ptr((t)),(n),strlen((n))+1))
+#define MATCH_OP(t,n)   ((t) && PST_UNKNOWNTYPE((t)) && !strncmp(pst_data_ptr((t)),(n),strlen((n))+1))
 
 #define RELEASE_TOK(t) if ((t) != NULL) {\
   pst_release_obj((t));\
```

---
Masamichi Hosoda <trueroad at trueroad.jp>