Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCP: PCRE2 support. #424

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

SCP: PCRE2 support. #424

wants to merge 2 commits into from

Conversation

bscottm
Copy link
Contributor

@bscottm bscottm commented Sep 27, 2024

Add PCRE2 support as an alternative to the original PCRE. PCRE2 is actively maintained and has a cleaner API than its predecessor.

  • Use a function interface around regular expressions to isolate and reduce the preprocessor #if/#endif forest. Abide by a single function declaration/implementation approach, vs. multiple function implentations within an #if/#endif forest.

  • Clean up the code so that work isn't recreated or duplicated, such as compiling regexps.

Platform notes:

  • cmake: PCRE2 is the default RegEx support. To revert to PCRE, add "-DPREFER_PCRE" to the cmake configuration command line.

  • makefile: PCRE remains the default RegEx support out of respect for tradition (cue Chaim Topol singing "Tradition".) Enable PCRE2 by defining "USE_PCRE2=" from the make command line or shell environment.

  • Visual Studio Projects: Untouched. Externally built libraries provide regular expression support residing in a specific place in the file system, which is outside the control of SIMH proper.

sim_defs.h:

  • Change EXPECT::size from int32 to size_t for increased cross-platform/64-bit compatibility (i.e., array indices and offsets should be size_t, where practicable.)

  • Add typedefs for EXPECT regex support independence: sim_regex_t, sim_re_capture_t.

  • Add regular expression context to EXPTAB that maintains state when processing the captured matches, making the function interface clean. Tracks intermediate state while processing captured matches.

Add PCRE2 support as an alternative to the original PCRE. PCRE2 is
actively maintained and has a cleaner API than its predecessor.

- Use a function interface around regular expressions to isolate and
  reduce the preprocessor #if/#endif forest. Abide by a single function
  declaration/implementation approach, vs. multiple function
  implentations within an #if/#endif forest.

- Clean up the code so that work isn't recreated or duplicated, such as
  compiling regexps.

Platform notes:

- cmake: PCRE2 is the default RegEx support. To revert to PCRE, add
  "-DPREFER_PCRE" to the cmake configuration command line.

- makefile: PCRE remains the default RegEx support out of respect for
  tradition (cue Chaim Topol singing "Tradition".) Enable PCRE2 by
  defining "USE_PCRE2=<some value>" from the make command line or shell
  environment.

- Visual Studio Projects: Untouched. Externally built libraries provide
  regular expression support residing in a specific place in the file
  system, which is outside the control of SIMH proper.

sim_defs.h:

- Change EXPECT::size from int32 to size_t for increased
  cross-platform/64-bit compatibility (i.e., array indices and offsets
  should be size_t, where practicable.)

- Add typedefs for EXPECT regex support independence: sim_regex_t,
  sim_re_capture_t.

- Add regular expression context to EXPTAB that maintains state when
  processing the captured matches, making the function interface clean.
  Tracks intermediate state while processing captured matches.
@Rhialto
Copy link
Contributor

Rhialto commented Sep 30, 2024

Having different defaults for make and cmake seems like a bad idea to me. If you think PCRE2 is better, just make it default in both.

@bscottm
Copy link
Contributor Author

bscottm commented Oct 2, 2024

@Rhialto: There's a reason for a different Makefile default, notably putting a cork in the inevitable whine. In principle, though, I agree that CMake and make should be congruent.

@pkoning2
Copy link
Member

pkoning2 commented Oct 2, 2024

What whine? I don't think whiners get to decide what is technically correct. From a technical point of view, it seems the two should match, and it sounds like you agree. Could you make the necessary change?

@markpizz
Copy link
Contributor

markpizz commented Oct 3, 2024

Changing from libpcre to libpcre2 doesn't actually fix anything in scp nor does it add absolutely any functionality to simh. It therefore is merely change for the sake of change. When @bscottm first proposed this change several years back, I looked at how many times per week the source for libpcre was downloaded vs the source for libpcre2. At that time, libpcre was downloaded some 5 times more than libpcre2. Since nothing was added I rejected this suggestion at that time.

It is quite likely that that ratio might be slightly different today, but probably not much since most of those projects never needed any of the new functionality that libpcre2 provides.

@bscottm
Copy link
Contributor Author

bscottm commented Oct 3, 2024

@pkoning2: My sardonic humor got me in trouble again. I'm happy to make the change, just don't want long missives about why pcre2 isn't necessary.

@markpizz: SIMH may not use all of PCRE2's features, but that shouldn't stand in the way of keeping infrastructural software current. libpcre2 is the more current of the two and I haven't taken away PCRE support, if you want it. That's why I made the makefile default is PCRE, so if you decided in integrate this PR into your tree, you wouldn't be inconvenienced.

Remove the USE_PCRE2 makefile variable so that the makefile's
configuration searches for PCRE2 and falls back to PCRE if not found.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants