[lldb-dev] regex vs regexp
Bruce Mitchener
bruce.mitchener at gmail.com
Sat Jul 5 06:34:02 PDT 2014
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 <linenum> is in decimal and <address> 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 <linenum> is in decimal and
<address> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140705/06cec848/attachment.html>
More information about the lldb-dev
mailing list