Re: [OB] cli/cli-script.c, null ptr guard

[msnyder@sonic.net]

> On Thu, Jun 28, 2007 at 04:04:29PM -0700, Michael Snyder wrote:
>> > On Thu, Jun 28, 2007 at 03:17:18PM -0700, msnyder@sonic.net wrote:
>> >> > No, I don't think this is obvious.  What does it mean to have a
>> null
>> >> > string here and how can it happen?  I'm pretty sure it can't, and
>> the
>> >> > if check is just clutter.
>> >>
>> >> The reasoning is that, since we checked it for NULL in the
>> >> first statement of the function, we must believe that the
>> >> possibility exists for it to be NULL.
>> >
>> > Right.  So, is it a sensible check?  Or should it be removed, or
>> > should the condition for the error be simplified?
>>
>> Well, it either makes sense to check it for null, or it doesn't.
>> If the new test is redundant, so is the old one.  Whoever wrote
>> it in the first place seemed to think it was worth checking.
>>
>> This is called from a number of places, but they are all local to the
>> module.
>>
>> Ultimately the argument comes from the command parser.
>> It's one of those typical (char *args, int from_tty) things.
>
> There's four calls to build_command_line.  Three are passed a freshly
> incremented pointer, so it can never be NULL.  That's
> if/while/commands.  The other one came from get_command_line.  Those
> can be NULL - well, I'm not sure, but I think they can.  They're
> always if/while.
>
> So how about adding gdb_assert (args != NULL) after the error call,
> like below?  If you follow where the result of this function goes,
> if we actually set cmd->line = NULL we will crash.

Yes, OK, will commit as shown.