Hello Ze'ev,
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"
main()
{
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);
exit(1);
}
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);
regfree(&preg);
}
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
Bernd
Am 18.02.2015 um 18:58 schrieb Ze'ev Atlas:
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!
Ze'ev Atlas
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
