diff options
author | Andrew Burgess <aburgess@redhat.com> | 2025-04-13 14:01:59 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2025-04-14 09:29:15 +0100 |
commit | 29b68e449be8816505487ef7cd5abde72ed21ca4 (patch) | |
tree | 0b0938ae72e152d251fa1b9d63b7e165f7a0a04a /libctf/testsuite/libctf-regression/pptrtab-b.c | |
parent | 6ef74a3985befe3cb07a64d089ff00694f4674dd (diff) | |
download | binutils-29b68e449be8816505487ef7cd5abde72ed21ca4.zip binutils-29b68e449be8816505487ef7cd5abde72ed21ca4.tar.gz binutils-29b68e449be8816505487ef7cd5abde72ed21ca4.tar.bz2 |
gdb: add an assert to cmd_list_element constructor
The cmd_list_element::doc variable must be non-nullptr, otherwise, in
`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run
one of these lines:
gdb_puts (c->doc, stream);
or,
gdb_puts (alias->doc, stream);
as gdb_puts requires that the first argument (the doc string) be
non-nullptr.
Better, I think, to assert when the cmd_list_element is created,
rather than catching an assert later when 'help CMD' is used.
I only ran into this case when messing with the Python API command
creation code, I accidentally created a command with a nullptr doc
string, and only found out when I ran 'help CMD' and got an
assertion.
While I'm adding this assertion, I figure I should also assert that
the command name is not nullptr too. Looking through cli-decode.c,
there seems to be plenty of places where we assume a non-nullptr name.
Built and tested on x86-64 GNU/Linux with an all-targets build; I
don't see any regressions, so (I hope) there are no commands that
currently violate this assertion.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'libctf/testsuite/libctf-regression/pptrtab-b.c')
0 files changed, 0 insertions, 0 deletions