× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott, et al.

This is interesting - just looked at the <regex.h> member in QSYSINC - yes, I know I'm mixing styles there!! The docs (fairly recent, I believe) show some flags for regcomp - including REG_EXTENDED. Even the V6R1 C/C++ Runtime reference does not include all the flags, however - there is a strange mix between the include member and the docs. Now as far as things go, there are 2 flags - REG_BASIC and the aforementioned REG_EXTENDED that probably affect the things you can do.

So to list some of the oddities -
1. C/C++ Runtime include file section lists various cflags values, including REG_BASIC & REG_EXTENDED.
2. The documentation for regcomp does not list REG_BASIC - it also lists a new value REG_ALT_NL.
3. The include member in QSYSINC/H(REGEX) lists all the values.
4. That member also tests for the define __POSIX_LOCALE__ which (I'm guessing here) is set by the system whenever the compile LOCALETYPE is not *CLD. If set to *CLD, regex cannot even be used, apparently. At least, in C/C++ - not sure the relationship with RPGLE.
5. The docs mention LOCALETYPE values of *LOCALE and *LOCALEUTF - but there is also a value of *LOCALEUCS2 that was there at V5R1 at least.

Note: LOCALETYPE is not a parameter on CRTRPGMOD - not sure how that is handled at this time. Have also not looked very far - not at all, in fact. I did see that our machine has QLOCALE set to *NONE - and other values are *C and *POSIX - ooh, there is the magic word.

6. The REGEX include member at V5R3 has mention of that REG_ALT_NL value and it distinguishes between POSIX and UTF32 - not sure how this relates to the values listed on number 5 above.

So I see a mix of POSIX and other stuff - I believe the system is POSIX-compliant, but REGEX might not be.

So that's all I know - and that's not much. I do know we use the regex functions in one of our products and it works adequately for our needs. We do recommend fairly simple expressions, however.

HTH
Vern
-------------- Original message --------------
From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>

Adam Glauser wrote:
Not to put words in Aaron's mouth, but I suspect that when he's using \s
and \S he's looking for whitespace and non-whitespace respectively. Do
the C regex APIs support Extended Regular Expression syntax,
specifically the shorthand character classes? [1]

snip

Perhaps IBM's biggest crime in this situation is it's HORRIBLE
documentation. The docs say NOTHING about what is and is not supported
in their regcomp() API. The only thing I can find in the docs is this:

"The functions regcomp(), regerror(), regexec(), and regfree() use
regular expressions in a similar way to the UNIX® awk, ed, grep, and
egrep commands."

Gee, thanks. Not the same as those commands (which, in themselves vary
widely) but "similar to" without any further explanation. Leaving us to
determine which regular expressions are and are not supported by
trial-and-error.

But -- my guess is that they only support the original Basic and
Extended regexp syntax... not the POSIX or Perl or Java, etc, extensions.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.