)]}'
{
  "commit": "29b68e449be8816505487ef7cd5abde72ed21ca4",
  "tree": "0b0938ae72e152d251fa1b9d63b7e165f7a0a04a",
  "parents": [
    "6ef74a3985befe3cb07a64d089ff00694f4674dd"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Sun Apr 13 14:01:59 2025 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Mon Apr 14 09:29:15 2025 +0100"
  },
  "message": "gdb: add an assert to cmd_list_element constructor\n\nThe cmd_list_element::doc variable must be non-nullptr, otherwise, in\n`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run\none of these lines:\n\n      gdb_puts (c-\u003edoc, stream);\n\nor,\n\n      gdb_puts (alias-\u003edoc, stream);\n\nas gdb_puts requires that the first argument (the doc string) be\nnon-nullptr.\n\nBetter, I think, to assert when the cmd_list_element is created,\nrather than catching an assert later when \u0027help CMD\u0027 is used.\n\nI only ran into this case when messing with the Python API command\ncreation code, I accidentally created a command with a nullptr doc\nstring, and only found out when I ran \u0027help CMD\u0027 and got an\nassertion.\n\nWhile I\u0027m adding this assertion, I figure I should also assert that\nthe command name is not nullptr too.  Looking through cli-decode.c,\nthere seems to be plenty of places where we assume a non-nullptr name.\n\nBuilt and tested on x86-64 GNU/Linux with an all-targets build; I\ndon\u0027t see any regressions, so (I hope) there are no commands that\ncurrently violate this assertion.\n\nApproved-By: Simon Marchi \u003csimon.marchi@efficios.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "217afbc8ca7fa5f2f840209177194e2ec0ade2dc",
      "old_mode": 33188,
      "old_path": "gdb/cli/cli-decode.h",
      "new_id": "9be446fb64194c26ce3ab0f0c18441654995a14c",
      "new_mode": 33188,
      "new_path": "gdb/cli/cli-decode.h"
    }
  ]
}
