Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

IBM-MAIN - Problem bei Kommunikation zwischen C und COBOL (PCRE)


Re: A possible bug in the IBM Runtimne C library


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>


IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>


2015.02.18 20:23:57

Hello Z.,

I post your source once again, because it was split into different lines and not
very readable.

#include <regex.h>
#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
extern void DUMPMEM(char *address, int length);
#include "zatoolib.h"
  regex_t preg;
  char *string = "a simple string";
  char *pattern = ".*(simple).*";
  int rc;
  size_t nmatch = 2;
  regmatch_t pmatch[2];
  int my_size = sizeof(pmatch)*2;
  if ((rc = regcomp(&preg, pattern, REG_EXTENDED)) != 0)
   printf("regcomp() failed, returning nonzero (%d)\n", rc);
  if ((rc = regexec(&preg, string, nmatch, pmatch, 0)) != 0)
   printf ("failed to ERE match '%s' with '%s',returning %d.\n",
   string, pattern, rc);
  DUMPMEM ((char *)pmatch, my_size);

I would like to know the exact definition of regmatch_t.

And I have some further questions:

a) long is the same as int with 32-bit C, so you only get a doubleword using
long, if you compile your source using the mainframe C compiler with the 64-bit
switches on (I hope this is possible; we always use the 32 bit option on z/OS,
64 bit only on Linux ... and on other platforms).

b) when looking at your source, I believe that the definition and the use of
my_size in DUMPMEM is wrong, because sizeof(pmatch) already is the size of the
array pmatch, which is the size of two elements of type regmatch_t. If you
multiply this by two, you get the double size of array pmatch, and then you dump
an area double as large as pmatch.

Don't know if this helps ...

Kind regards


Am 18.02.2015 um 18:58 schrieb Z.A.:

> One of the machines is rather old and one is much more current (1.6 vs 1.10 I
> believe but will check again tonight - I am only a user)
> I did it with COBOL 4.2 and 5.1 with same results.  I do not remember the C
> compiler levels but the behavior was consistent, and WRONG in all combinations.
> I provided the C program in order to remove the complexity of C to COBOL
> interface.  I would ask that somebody should check it on your machine (replace
> the DUMPMEM with printf in Hex).  If it happens on your latest and greatest
> version, than I have a point.
> It does not matter whether the bug is in the library itself or in the language
> (C, COBOL, whatever) to library interface; I used the thing in the most common,
> no frills way, as is described in the manual, interfacing two different standard
> languages and got a problem.  Either the manual is wrong or the library or the
> interface.  It is clearly not a user programming issue.
> If anybody may overcome this issue by using some clever compile options than
> be it, but I do not think so!
> Z.
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie