Re: A possible bug in the IBM Runtimne C library
I still do not know how to make PL/I communicate with C, but COBOL and C communicate like a pair of newlyweds once this was resolved. ZA, Chapter 8 and 9 from this manual might help you. Sample programs in section 8.9 and 9.8 might be what you are looking at. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA4180/CCONTENTS Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Obviously, I know that and I realized that the issue is integral boundaries! I am dealing with COBOL, not PL/I but the real issue was that the order is the other way around (i.e. the fullword is first and the halfword is second, leaving a two bytes gap unaccounted for after every pair. So I resolved it by adding a dummy two bytes variable in the end of each pair: 10 A PIC 9(9) COMP-5. 10 B PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next pair 10 D PIC 9(9) COMP-5. 10 E PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next element This works fine. I still do not know how to make PL/I communicate with C, but COBOL and C communicate like a pair of newlyweds once this was resolved. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
On Mon, 23 Feb 2015 12:15:09 -0600, Ze'ev Atlas zatl...@yahoo.com wrote: So I resolved it by adding a dummy two bytes variable in the end of each pair: 10 A PIC 9(9) COMP-5. 10 B PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next pair You might want to use the SYNC keyword for this, instead of adding filler. I still do not know how to make PL/I communicate with C, but COBOL and C communicate like a pair of newlyweds once this was resolved. Glad you got it to work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Ze'ev Atlas wrote: Obviously, I know that and I realized that the issue is integral boundaries! So I resolved it by adding a dummy two bytes variable in the end of each pair: 10 A PIC 9(9) COMP-5. What are you doing to ensure that A starts on a full word? In other words, what is declared before it and ending of course in a full word boundary? 10 B PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next pair Hmmm, I need to compile a sample program and see for myself the layout. ... but COBOL and C communicate like a pair of newlyweds once this was resolved. Good analogy, just be careful of a divorce during honeymoon! ;-) I'm glad you solved your problem. Does that means all your questions in two threads this month are now resolved? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
I guess I will use SYNC to ensure all integral boundaries... next release :) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
The SYNCHRONIZED clause is new to me (I do not code COBOL on regular basis any more.) I will incorporate that in the next release. Thanks to all who had suggested it ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Thanks Kolusu I will look into the PL/I interface for both this and the PCRE... maybe next release ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
To give you an example on the different alignment strategy of (for example)
PL/1 and C:
let's assume a structure
typedef struct
{
short a;
int b;
short c;
int d;
}
example;
in PL/1;
DCL 1 EXAMPLE,
3 A BIN FIXED (15),
3 B BIN FIXED (31),
3 C BIN FIXED (15),
3 D BIN FIXED (31);
These two definitions will not match, because:
in C there are two padding bytes after a and after c; the whole structure
starts at an address multiple of 4, because there are ints inside the
structure.
In PL/1, B has to be on a 4 byte boundary. To save padding bytes, the
beginning
of the structure will be in the middle of a full word, that is: on an
offset that has
remainder 2 when divided by 4. So the offsets of the structure
components are
different; when the structures are overlaid, the fields don't match.
To get around this, we put dummy double precisions fields (with the
highest possible
alignment needs) in the front of every such structure. Then the offsets
and paddings
of the remaining fields will be in sync.
(BTW: if there are multiple instances of the PL/1 structure, for example
in an array,
the PL/1 technique does not save anything, because the padding fields
now appear
at the end of the structure ... before the next element begins).
Kind regards
Bernd
Am 23.02.2015 um 08:37 schrieb Bernd Oppolzer:
Hello Ze'ev,
unless the structure is defined with the nonstandard extension Packed
(or _Packed, I don't recall it exactly), all ints or longs will be
aligned on
a 4 byte boundary, that is, in a sequence of int, short, int, short,
you will
get two padding bytes after every short field (which is in fact 2
bytes long).
Same goes for PL/1 with a sequence of BIN FIXED(31) and BIN FIXED(15)
fields. The rules for alignment with PL/1 are more complicated than
with C.
Structures in C always start with the highest needed alignment
required inside
the structure, while in PL/1 there is some work done to start the
structure at
an offset which minimizes the padding bytes in the middle of the
structure
(short story, the long explanation in the PL/1 books needs many pages).
You can synchronize alignment between PL/1 and C, if you put a dummy
double precision field (which has alignment requirement of 8) in front
of the structure.
The the two languages do the same. A similar technique should work for
COBOL, too.
Kind regards
Bernd
Am 23.02.2015 um 03:44 schrieb Ze'ev Atlas:
__off_t is clearly defined earlier as a 32 bit entity but mbstate_t
is defined as short which I assumed is a 16 bit entity. Either short
is NOT 16 bits but 32 bit entity as well, or the C compiler leaves 2
bytes of zeroes in order to keep the correct integral boundary.
However, in REAL LIFE there are 32 bits between rm_so and rm_eo. I
did not bother to investigate too much ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Hello Ze'ev, unless the structure is defined with the nonstandard extension Packed (or _Packed, I don't recall it exactly), all ints or longs will be aligned on a 4 byte boundary, that is, in a sequence of int, short, int, short, you will get two padding bytes after every short field (which is in fact 2 bytes long). Same goes for PL/1 with a sequence of BIN FIXED(31) and BIN FIXED(15) fields. The rules for alignment with PL/1 are more complicated than with C. Structures in C always start with the highest needed alignment required inside the structure, while in PL/1 there is some work done to start the structure at an offset which minimizes the padding bytes in the middle of the structure (short story, the long explanation in the PL/1 books needs many pages). You can synchronize alignment between PL/1 and C, if you put a dummy double precision field (which has alignment requirement of 8) in front of the structure. The the two languages do the same. A similar technique should work for COBOL, too. Kind regards Bernd Am 23.02.2015 um 03:44 schrieb Ze'ev Atlas: __off_t is clearly defined earlier as a 32 bit entity but mbstate_t is defined as short which I assumed is a 16 bit entity. Either short is NOT 16 bits but 32 bit entity as well, or the C compiler leaves 2 bytes of zeroes in order to keep the correct integral boundary. However, in REAL LIFE there are 32 bits between rm_so and rm_eo. I did not bother to investigate too much ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
I want to publicly thank Retired Mainframer for leading me to the correct
direction. The problem was that the EBCDIC oriented regmatch_t structure is
defined like this:
typedef struct { /* substring locations - from regexec() */
__off_t rm_so; /* offset of substring */
mbstate_t rm_ss; /* Shift state at start of substring*/
__off_t rm_eo; /* offset of first char after substring */
mbstate_t rm_es; /* Shift state at end of substring */
} regmatch_t;
__off_t is clearly defined earlier as a 32 bit entity but mbstate_t is defined
as short which I assumed is a 16 bit entity. Either short is NOT 16 bits but
32 bit entity as well, or the C compiler leaves 2 bytes of zeroes in order to
keep the correct integral boundary. However, in REAL LIFE there are 32 bits
between rm_so and rm_eo. I did not bother to investigate too much but
translated the structure as:
10 :PREFIX:-regmatch-t.
15 :PREFIX:-rm-so PIC S9(9) COMP-5.
* offset of substring */
15 :PREFIX:-rm-ss PIC s9(4) COMP-5.
* Shift state at start of substring*/
15 FILLER PIC XX.
* The filler was added since despite the fact that the C
* calls for short rm-ss and rm-es (i.e. S9(4) COMP-5) allocates
* 4 bytes, either because short is not short after all or
* because of integral boundary.
15 :PREFIX:-rm-eo PIC S9(9) COMP-5.
* offset of first char after substring */
15 :PREFIX:-rm-es PIC S9(4) COMP-5.
* Shift state at end of substring */
15 FILLER PIC XX.
compensating for the additional two bytes after each pair. After all, we
always use EBCDIC!
I've published the results of my work as FILE928 in the CBTTAPE with a demo
program and explanation how to extract a captured substring (in addition to the
regular match/no-match capability.
I will also publish it in my own website later.
The reason for this work is that the only serious argument I've ever heard for
not using my port of the PCRE library was that management would never allow
use of Open Source. One can freely take my copybooks that only describe
structures and use them with the bona-fide IBM supplied functions. Please feel
free to copy the definition only and avoid the open Source mambo Jumbo if you
do not intend to distribute your poor COBOL program!
ZA
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
While I agree on that on a philosophical point of view, what are the real technical implication of that C design decision? Every 20 years, when there is a major architecture extension (for example 32 bit to 64 bit), some work has to be done, when for example long changes the meaning from 32-bit to 64-bit to keep the applications running. Nowadays it is an error to use long, if you want a 32 bit value, because it is different on some platforms, whereas int is 32 bit on almost every relevant platform. This was different 20 years ago, when int was 16 bits (like short) on certain relevant platforms, so you had to use long to get 32 bits on every relevant platform. You have two choices: a) use the standard type (like int or long) that matches the size you need at all the platforms that are relevant to you ... this will work normally for a long period of time, and after that, you will have some work to do to examine your sources and to keep your application running (see example below), or b) use own types via typedef, and define them depending on the platform (macro language) Here is what I had to do, when I had to convert a large insurance math package to make it run on a Linux 64-bit platform: - change all long declarations to int (I did this using a program that changed all the sources) - change all %ld tags in printf and sprintf etc to %d etc (this was also done using the same program, in fact the program was built from scratch to do all that and it was refined during the process) - because all pointers changed the size from 4 to 8 bytes, there were some dependencies inside the code, where offsets of fields inside structures where calculated; these calculations had to be eliminated or corrected Although the number of source lines was in the 1 million area, I got it done within 3 weeks. I had several thousand regression testcases and a testdriver which allowed me to test the outcome of the math package before and after the change on the different platforms (Win 32, Linux 64). Without that, the whole conversion would not have been possible. So my conclusion is: such a migration is a large effort, anyway. You will get changes from the architecture change anyway, no matter if your longs change size or not. It is a project. PL/1, for example, doesn't even have a 64-bit variant (for example on z/OS). While I agree that the C language has its flaws, it allows for many things that other languages don't. Kind regards Bernd Am 20.02.2015 um 00:17 schrieb Shmuel Metz (Seymour J.): In 1346088131080403.wa.zatlas1yahoo@listserv.ua.edu, on 02/19/2015 at 08:18 AM, Ze'ev Atlas 004b34e7c98a-dmarc-requ...@listserv.ua.edu said: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. It was appalling; a reversion to FORTRAN-speak after PL/I showed how it should[1] be done. But C is still the best PDP-7 specific language ever designed. [1] In general; I won't argue the Ada approach versus the PL/I approach, as both let the compiler figure out what storage unit is needed to hold the declared variable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
On Thu, 19 Feb 2015 08:18:05 -0600, Ze'ev Atlas zatl...@yahoo.com wrote: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. You can always use int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t and friends in /usr/include/stdint.h. ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Sure I could, but the geniuses who created the regex.h and friends did not deem that necessary, so the poor user has to go to the header file, read all the #if's and #else's and figure it our. Not an easy task when you are a COBOL poor user :( ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
I am going back to the drawing board and I will have a hard look at the regex.h again and will do some tests with 64 bits compilations vs. 32 bits. It is extremely hard to deduce from the documentation what to expect and what structure is in effect when one compiles with any combination of pragma's/macros, etc. Than, when I know better, I'll still have the task of apply that knowledge to COBOL compilation combination. I assume now that COBOL and C when compiled under normal LE environment communicate somehow with the library to produce the correct structures in reality. If I am correct, I just have to trace the rules and translate them to appropriate copybooks. I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
In 1346088131080403.wa.zatlas1yahoo@listserv.ua.edu, on 02/19/2015 at 08:18 AM, Ze'ev Atlas 004b34e7c98a-dmarc-requ...@listserv.ua.edu said: I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. It was appalling; a reversion to FORTRAN-speak after PL/I showed how it should[1] be done. But C is still the best PDP-7 specific language ever designed. [1] In general; I won't argue the Ada approach versus the PL/I approach, as both let the compiler figure out what storage unit is needed to hold the declared variable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
The data in your dump does not seem to support your conclusion. If you treat the first four bytes as a stand-alone word, you do indeed get a word of 0 and a long of 15. But the next two longs are 2 and 8, not the 8 and 2 you are expecting. If you treat all the data as longs, you get values of 0, 15, 2, and 8 but not in the normal order of a big endian machine. For whatever reason, each long seems to be ordered as low order word followed by high order word. Or perhaps each long only contains a word. Could it have something to do with whether you are in 32 or 64 bit mode. In 32 bit mode, a long is only 4 bytes while in 64 bit mode it is 8. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ze'ev Atlas Sent: Wednesday, February 18, 2015 6:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: A possible bug in the IBM Runtimne C library Hi all I suspect (and can prove that there is a bug in the regexec function. I have encountered this issue on two z/OS systems with two different z/OS level. The proof is repeatable and produce same wrong results any time. To prove it I modified a sample C program from the IBM manual and added a call for dumping memory (see below). The documentation and the regex.h declare that the regmatch_t construct should be a pair of doublewords (long) and it is supposed to be an element in an array of as many as you need. Iinstead of getting two pairs of double words containing (0,15),(8,2), I get the first component of the first element as one word (int) of 0 and the rest are indeed double words. This seems like a bug in the runtime library.Here is the dump (only the first two lines are relevant) 19819478 | 00 00 00 0000 00 00 0000 00 00 0F00 00 00 00 | 19819488 | 00 00 00 0200 00 00 0000 00 00 0800 00 00 00 | 19819498 | 00 00 00 4000 00 00 0010 00 00 0019 81 92 48 | ak 198194A8 | 00 00 00 00 99 80 01 6E 04 C6 3C 98 00 00 00 00 | r K F q -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
I am sorry for the typo, I was expecting (0,15),(2,8) and not (0,15),(8,2) long 0 long 15 long 2 long 8 I ran it in z/OS which should default to normal numbers so all classic LE languages would understand it correctly 19819478 | 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 | 19819488 | 00 00 00 02 00 00 00 00 00 00 00 08 00 00 00 00 | However, your suggestion that For whatever reason, each long seems to be ordered as low order word followed by high order word. seems to answer the issue. If you are correct, then, the library provides an integer and a filler of 4 bytes. This explanation seems to be reasonable. Could anybody who is more C savvy and proficient with the runtime library usage, point to any proof that this is indeed the answer? Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Thank you for reposting The use of my_size was indeed wrong, so I dumped more than I needed. Only first two lines are relevant! I did not want to compile and run again because it was late at night I do not have access now, but the definition of regmatch_t is in the regex.h. Regardless of that definition, the library functions gives me back: 1 variable of 32 bits 3 variables of 64 bits I would not mind if I get 4 variables of 32 bits or 4 variables of 64 bits, I could handle each possibility, but the runtime consists of load modules and does not depend on my compile options. The library function may be super smart and communicate with my program based on how I compile it (32 or 64 bits) but it has to do it consistently! The problem is that the results are inconsistent and cannot be explained neither by what z/OS is used, nor by what language or compiler options are used. I ask again, please repeat my test and if you get same results, report it to IBM (I do not have any standing with IBM, but you may have!) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: A possible bug in the IBM Runtimne C library
Ze'ev Atlas wrote: I suspect (and can prove that there is a bug in the regexec function. I have encountered this issue on two z/OS systems with two different z/OS level. The proof is repeatable and produce same wrong results any time. What levels of C libraries and z/OS are you using? Is this related to your other question you posted today? If so, what level of COBOL are you using too? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A possible bug in the IBM Runtimne C library
Hi all
I suspect (and can prove that there is a bug in the regexec function. I have
encountered this issue on two z/OS systems with two different z/OS level. The
proof is repeatable and produce same wrong results any time.
To prove it I modified a sample C program from the IBM manual and added a call
for dumping memory (see below). The documentation and the regex.h declare that
the regmatch_t construct should be a pair of doublewords (long) and it is
supposed to be an element in an array of as many as you need. Iinstead of
getting two pairs of double words containing (0,15),(8,2), I get the first
component of the first element as one word (int) of 0 and the rest are indeed
double words. This seems like a bug in the runtime library.Here is the dump
(only the first two lines are relevant)
19819478 | 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 |
19819488 | 00 00 00 02 00 00 00 00 00 00 00 08 00 00 00 00 |
19819498 | 00 00 00 40 00 00 00 00 10 00 00 00 19 81 92 48 |
ak198194A8 | 00 00 00 00 99 80 01 6E 04 C6 3C 98 00 00 00 00 | r K F q
I do not have contacts with IBM. Would any one of you please pick up the issue
with IBM so they can explain or fix it. I think that some people in IBM
monitor this list, so please, could you help.
Here is the program
#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);
}
Ze'ev Atlas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
