From 7abc6ec0a6f7e82bda6f00c1f1ae7c638d1c799c Mon Sep 17 00:00:00 2001 From: Andrew Burgess Date: Wed, 14 Sep 2022 13:51:28 +0100 Subject: 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. --- gdb/doc/python.texi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'gdb/doc') 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 -- cgit v1.1