regex vs regexp

This is perhaps being overly picky, but there are usages in the UI of both “regex” and “regexp”.

These use regexp:

(lldb) apropos regexp

The following built-in commands may relate to ‘regexp’:

_regexp-attach – Attach to a process id if in decimal, otherwise treat the argument as a process name to attach to.

_regexp-break – Set a breakpoint using a regular expression to specify the location, where is in decimal and is in hex.

_regexp-display – Add an expression evaluation stop-hook.

_regexp-down – Go down “n” frames in the stack (1 frame by default).

_regexp-env – Implements a shortcut to viewing and setting environment variables.

_regexp-jump – Sets the program counter to a new address.

_regexp-list – Implements the GDB ‘list’ command in all of its forms except FILE:FUNCTION and maps them to the appropriate ‘source list’ commands.

_regexp-tbreak – Set a one shot breakpoint using a regular expression to specify the location, where is in decimal and is in hex.

_regexp-undisplay – Remove an expression evaluation stop-hook.

_regexp-up – Go up “n” frames in the stack (1 frame by default).

breakpoint – A set of commands for operating on breakpoints. Also see _regexp-break.

breakpoint set – Sets a breakpoint or set of breakpoints in the executable.

thread step-in – Source level single step in specified thread (current thread, if none specified).

thread step-inst – Single step one instruction in specified thread (current thread, if none specified).

thread step-inst-over – Single step one instruction in specified thread (current thread, if none specified), stepping over calls.

thread step-out – Finish executing the function of the currently selected frame and return to its call site in specified thread (current thread, if none specified).

thread step-over – Source level single step in specified thread (current thread, if none specified), stepping over calls.

The following settings variables may relate to ‘regexp’:

target.process.thread.step-avoid-regexp – A regular expression defining functions step-in won’t stop in.

A bunch of other things use regex instead of regexp, including:

command alias – Allow users to define their own debugger command abbreviations.

command regex – Allow the user to create a regular expression command.

frame variable – Show frame variables. All argument and local variables that are in scope will be shown when no arguments are given. If any arguments are specified, they can be names of argument, local, file static and file

global variables. Children of aggregate variables can be specified such as ‘var->child.x’.

platform process list – List processes on a remote platform by name, pid, or many other matching attributes.

target modules lookup – Look up information within executable and dependent shared library images.

target variable – Read global variable(s) prior to, or while running your binary.

type filter add – Add a new filter for a type.

type filter list – Show a list of current filters.

type format add – Add a new formatting style for a type.

type format list – Show a list of current formatting styles.

type summary add – Add a new summary style for a type.

type summary list – Show a list of current summary styles.

type synthetic add – Add a new synthetic provider for a type.

type synthetic list – Show a list of current synthetic providers.

The following settings variables may relate to ‘regex’:

interpreter.expand-regex-aliases – If true, regular expression alias commands will show the expanded command that will be executed. This can be used to debug new regular expression alias commands.

In the repository, there are about 980 references to regex and about 210 references to regexp.

Is this something that anyone else cares about? Is it too late to fix it (due to compatibility)?

I suspect that ‘regex’ is the preferred spelling due to the count of usages in the codebase and that the implementation is llvm_regex_t and so on.

  • Bruce

I don't think we should change anything in the command/settings names. For instance, folks may have re-aliased the _regexp_* commands to some other short name, and we'd break that with no compelling benefit. Ditto for SB API's. So we'd have to add the other as an alternative, which would almost be more confusing...

Anything internal can be standardized on regex, I don't have a strong feeling one way or the other.

Jim