Re: regexec - chopping a large text string into chunks

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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?