Remove some historic cruft

[NWilson]

I've asked before a few things (like the "NATIVE_ZOS" and VMS support). Those have stayed.

Here are a few more to consider:

• CUSTOM_SUBJECT_PTR. The comments say it's never even been tested with PCRE2. Either I test it... or remove it without testing. It's not doing any good as it is (given it's highly unlikely to work).

• The HAVE_MEMMOVE fallbacks. Really? We have raised our minimum compiler support to C99 in release 10.43, and for example some files now include a handful of // comments. No-one has complained, so clearly we don't have customers with C89 compilers - or at least, we surely don't have any with pre-C89 compilers. The last systems without memmove were SunOS4 (1988) and BSD 4.3 (1990). Ever since BSD 4.4 (1992) and Solaris (also 1992), everyone has had memmove. It's mandated by C89.

  My suggestion is to remove the HAVE_MEMMOVE check from CMake and Autoconf. I guess we could keep the fallback code in one place, perhaps, but the customer would have to pass in "NO_MEMMOVE" explicitly (we wouldn't try and automatically detect this configuration).

  Why do I care? Because I know that people take the source files from PCRE2 and put them in their own build systems. It's all pretty portable C99. The only caveat is that you need to know to pass in HAVE_MEMMOVE, or you get an old fallback. This is a burden that our build macros are imposing on actual modern systems. Better to invert HAVE_MEMMOVE to NO_MEMMOVE.

  Or better still... just remove it?

• The mentions of "UTF-21". There is no such thing. I can hardly find any record that it was even seriously proposed. If it was proposed, it never got very far. I don't think there ever has been or ever will be a UTF-21. GNU iconv has a ludicrous number of text encodings, but no UTF-21.

[MatthewVernon]

I think I'd be inclined to remove the HAVE_MEMMOVE fallbacks entirely at this point.

I //think// reading the comment around the macros that this was something @PhilipHazel thought he might implement at some point, but never got round to doing?

I have no opinions on C++ things :)

[PhilipHazel]

Matthew is quite correct. about CUSTOM_SUBJECT_PTR and UTF-21. The latter was never a reference to a standard encoding, but somebody (a long time ago now) wanted an option for PCRE just to ignore the most significant 11 bits of 32-bit words so that an application that was using them for other info could call PCRE without having to munge its strings. (Aside: in my PMW music typesetter I do put a font number in the top byte of 32-bit characters, but there's no use for PCRE in that application. :-) CUSTOM_SUBJECT_PTR was, IIRC, an idea to allow for loading characters other than from string pointers. Neither of these were ever more than vague ideas, and so much time has passed I agree that you should clean them out. Also agree about removing HAVE_MEMMOVE. In the very early days of PCRE there were still systems around that didn't have it; I implemented it because it was needed. But 30 years later???

[NWilson]

Great! Thanks for that information

[NWilson]

I've decided to also remove the strerror fallbacks. It's another function that's guaranteed by C89, and the old SunOS4 fallback is unlikely to be of use to anyone nowadays.