×
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.
Hi Vern,
So to list some of the oddities -
1. C/C++ Runtime include file section lists various cflags values, including REG_BASIC & REG_EXTENDED.
...not sure what your point is. We already know that the system
supports both REG_BASIC and REG_EXTENDED. The \s and \S are not part of
the standard for either basic or extended regular expressions,
therefore I'm not sure that I understand why you're brining it up?
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.
That's because REG_BASIC is the default. If REG_EXTENDED is turned on,
you're using extended. If REG_EXTENDED is turned off, you're using
basic. There's no need to set a flag to indicate that you want BASIC.
If you look at the value of the REG_BASIC macro in the C copybook, I
think you'll see that it's 0. What happens when you add 0 to something?
It doesn't change. Thus, that macro doesn't *do* anything.
It's probably there to make it easier to write code that's portable --
i.e. C code that works on both the i and other systems where REG_BASIC
might be required. It's not listed in the documentation because it
doesn't do anything.
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.
I'm not sure I understand your theory here... Are you confusing POSIX
locales with the POSIX extensions to regular expressions? Or.. why are
you investigating the locales? (Surely, this isn't a locale issue?!)
So I see a mix of POSIX and other stuff - I believe the system is POSIX-compliant, but REGEX might not be.
The system is definitely not POSIX-compliant! It has many features that
are POSIX-compliant, but the system as a whole definitely is not.
Keep in mind that the question is whether the system supports the POSIX
character class extensions to the regular expressions. Who cares
whether it supports POSIX locales or any other of the bazillion other
things that fall into POSIX standards?
midrange.com
