aboutsummaryrefslogtreecommitdiff
path: root/gdb/doc
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-09-14 13:51:28 +0100
committerAndrew Burgess <aburgess@redhat.com>2022-09-22 10:34:15 +0100
commit7abc6ec0a6f7e82bda6f00c1f1ae7c638d1c799c (patch)
treec25e132a81ec94cf1bb4d21fa844ef0cb35924c4 /gdb/doc
parent9c5f314314e2d14c7602a79b969e02ebdd8890ea (diff)
downloadfsf-binutils-gdb-7abc6ec0a6f7e82bda6f00c1f1ae7c638d1c799c.zip
fsf-binutils-gdb-7abc6ec0a6f7e82bda6f00c1f1ae7c638d1c799c.tar.gz
fsf-binutils-gdb-7abc6ec0a6f7e82bda6f00c1f1ae7c638d1c799c.tar.bz2
gdb/python: restrict the names accepted by gdb.register_window_type
I noticed that, from Python, I could register a new TUI window that had whitespace in its name, like this: gdb.register_window_type('my window', MyWindowType) however, it is not possible to then use this window in a new TUI layout, e.g.: (gdb) tui new-layout foo my window 1 cmd 1 Unknown window "my" (gdb) tui new-layout foo "my window" 1 cmd 1 Unknown window ""my" (gdb) tui new-layout foo my\ window 1 cmd 1 Unknown window "my\" GDB clearly uses the whitespace to split the incoming command line. I could fix this by trying to add a mechanism by which we can use whitespace within a window name, but it seems like an easier solution if we just forbid whitespace within a window name. Not only is this easier, but I think this is probably the better solution, identifier names with spaces in would mean we'd need to audit all the places a window name could be printed and ensure that the use of a space didn't make the output ambiguous. So, having decided to disallow whitespace, I then thought about other special characters. We currently accept anything as a window name, and I wondered if this was a good idea. My concerns were about how special characters used in a window name might cause confusion, for example, we allow '$' in window names, which is maybe fine now, but what if one day we wanted to allow variable expansion when creating new layouts? Or what about starting a window name with '-'? We already support a '-horizontal' option, what if we want to add more in the future? Or use of the special character '{' which has special meaning within a new layout? In the end I figured it might make sense to place some restrictive rules in place, and then relax the rules later if/when users complain, we can consider each relaxation as its requested. So, I propose that window names should match this regular expression: [a-zA-Z][-_.a-zA-Z0-9]* There is a chance that there is user code in the wild which will break with the addition of this change, but hopefully adapting to the new restrictions shouldn't be too difficult.
Diffstat (limited to 'gdb/doc')
-rw-r--r--gdb/doc/python.texi4
1 files changed, 3 insertions, 1 deletions
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 7aa9e85..2692211 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -6597,7 +6597,9 @@ factory function with @value{GDBN}.
@var{name} is the name of the new window. It's an error to try to
replace one of the built-in windows, but other window types can be
-replaced.
+replaced. The @var{name} should match the regular expression
+@code{[a-zA-Z][-_.a-zA-Z0-9]*}, it is an error to try and create a
+window with an invalid name.
@var{function} is a factory function that is called to create the TUI
window. This is called with a single argument of type