Strangeness in set command

Strangeness in set command

[Eli Zaretskii]

Assuming that `s' is a variable of type `struct stat', this command
fails:

  (gdb) set s.st_mode=0x1ff
  Ambiguous set command "s.st_mode=0x1ff"

But this succeeds:

  (gdb) set (&s)->st_mode=0x1ff

How come we are smart enough to support the latter, but not the
former?

Re: Strangeness in set command

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Assuming that `s' is a variable of type `struct stat', this command
> fails:
>
>   (gdb) set s.st_mode=0x1ff
>   Ambiguous set command "s.st_mode=0x1ff"
>
> But this succeeds:
>
>   (gdb) set (&s)->st_mode=0x1ff
>
> How come we are smart enough to support the latter, but not the
> former?

Because there are several set commands beginning with s.  Use set
variable to avoid the ambiguity.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Strangeness in set command

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: gdb@sources.redhat.com
> Date: Sat, 05 Apr 2008 18:45:04 +0200
> 
> >   (gdb) set s.st_mode=0x1ff
> >   Ambiguous set command "s.st_mode=0x1ff"
> >
> > But this succeeds:
> >
> >   (gdb) set (&s)->st_mode=0x1ff
> >
> > How come we are smart enough to support the latter, but not the
> > former?
> 
> Because there are several set commands beginning with s.  Use set
> variable to avoid the ambiguity.

Thanks.

Does anyone object to improving the error message to mention "set
variable"?

Re: Strangeness in set command

[Daniel Jacobowitz]

On Sat, Apr 05, 2008 at 08:12:43PM +0300, Eli Zaretskii wrote:
> Does anyone object to improving the error message to mention "set
> variable"?

I don't think it will help; it's just luck you got an ambiguity since
there are two commands starting with s.  You could get any number of
other errors, or even silent success.  Like:

(gdb) set ser.a = 1
Undefined set serial command: ".a = 1".  Try "help set serial".
(gdb) set args.a = 1
(gdb) show args
Argument list to give program being debugged when it is started is ".a = 1".


-- 
Daniel Jacobowitz
CodeSourcery

Re: Strangeness in set command

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Sat, Apr 05, 2008 at 08:12:43PM +0300, Eli Zaretskii wrote:
>> Does anyone object to improving the error message to mention "set
>> variable"?
> 
> I don't think it will help; it's just luck you got an ambiguity since
> there are two commands starting with s.  You could get any number of
> other errors, or even silent success.  Like:
> 
> (gdb) set ser.a = 1
> Undefined set serial command: ".a = 1".  Try "help set serial".
> (gdb) set args.a = 1
> (gdb) show args
> Argument list to give program being debugged when it is started is ".a = 1".

This has been bugging me for some time. Not just for interactive use, 
but also because it's quite easy to write scripts which work now, but 
might fail unexpectedly in future versions of GDB.

E.g.

(gdb) set index = 1

There's no GDB command "set index", so this sets a program variable, 
which is probably what the user intended. However, can you say for sure 
GDB will never use this name? It's exactly the sort of useful name that 
would find a use, and when it does a script with this command will go wrong.

Perhaps the best solution would be to print an expanded version, thus 
making it explicit what is going on.

E.g.

(gdb) set ser.a = 1
=> set serial .a = 1
Undefined set serial command: ".a = 1".  Try "help set serial".
(gdb) set args.a = 1
=> set args .a = 1
(gdb) show args
Argument list to give program being debugged when it is started is ".a = 1".

(gdb) set index = 1
=> set variable index = 1

I wouldn't recommend printing the command when no expansion is performed 
- that would really annoy me, especially when sourcing scripts - but I 
would suggest extending the feature to commands in scripts. Scripts 
could be silenced simply by making them explicit. This would encourage 
people to future proof their scripts.

Naturally, there would have to be a way to make the messages go away.

Just a thought

Andrew

Re: Strangeness in set command

[Michael Snyder]

On Sat, 2008-04-05 at 14:54 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 05, 2008 at 08:12:43PM +0300, Eli Zaretskii wrote:
> > Does anyone object to improving the error message to mention "set
> > variable"?
> 
> I don't think it will help; it's just luck you got an ambiguity since
> there are two commands starting with s.  You could get any number of
> other errors, or even silent success.  Like:
> 
> (gdb) set ser.a = 1
> Undefined set serial command: ".a = 1".  Try "help set serial".
> (gdb) set args.a = 1
> (gdb) show args
> Argument list to give program being debugged when it is started is ".a = 1".

I think the way to think about this is that the real
command is "set variable", and that "set " has been 
allowed as a shortcut command so long as the argument
is not ambiguous with another "set" command.

The problem is that "so long as it is not ambiguous"
is dicy, and changes over time as we add new subcommands
to "set".

The shortcut is probably one of those "seemed like a 
good idea at the time" things, but now it's established
and we're stuck with it.

It would probably be a good idea if, every time we parse
a "set" command, we try to match it with BOTH a variable
AND a subcommand, and if there is ambiguity we say so
explicitly.

Re: Strangeness in set command

[Eli Zaretskii]

> From: Michael Snyder <msnyder@specifix.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Andreas Schwab <schwab@suse.de>,  gdb@sources.redhat.com
> Date: Mon, 07 Apr 2008 12:05:59 -0700
> 
> The problem is that "so long as it is not ambiguous"
> is dicy, and changes over time as we add new subcommands
> to "set".
> 
> The shortcut is probably one of those "seemed like a 
> good idea at the time" things, but now it's established
> and we're stuck with it.
> 
> It would probably be a good idea if, every time we parse
> a "set" command, we try to match it with BOTH a variable
> AND a subcommand, and if there is ambiguity we say so
> explicitly.

Or maybe, if the text after "set " has a `=' character in it, we
should ask whether the user really meant "set variable".  IOW, refuse
to obey this shortcut, even if it's unambiguous.

Re: Strangeness in set command

[Andrew STUBBS]

Eli Zaretskii wrote:
>> From: Michael Snyder <msnyder@specifix.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Andreas Schwab <schwab@suse.de>,  gdb@sources.redhat.com
>> Date: Mon, 07 Apr 2008 12:05:59 -0700
>>
>> The problem is that "so long as it is not ambiguous"
>> is dicy, and changes over time as we add new subcommands
>> to "set".
>>
>> The shortcut is probably one of those "seemed like a 
>> good idea at the time" things, but now it's established
>> and we're stuck with it.
>>
>> It would probably be a good idea if, every time we parse
>> a "set" command, we try to match it with BOTH a variable
>> AND a subcommand, and if there is ambiguity we say so
>> explicitly.
> 
> Or maybe, if the text after "set " has a `=' character in it, we
> should ask whether the user really meant "set variable".  IOW, refuse
> to obey this shortcut, even if it's unambiguous.
> 

Hmmm, that's not great for set args:

(gdb) set args --command=myscript

Re: Strangeness in set command

[Eli Zaretskii]

> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
> 	version=3.1.0
> Date: Tue, 08 Apr 2008 11:57:46 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: Michael Snyder <msnyder@specifix.com>, drow@false.org,
> 	schwab@suse.de, gdb@sources.redhat.com
> 
> Eli Zaretskii wrote:
> > Or maybe, if the text after "set " has a `=' character in it, we
> > should ask whether the user really meant "set variable".  IOW, refuse
> > to obey this shortcut, even if it's unambiguous.
> > 
> 
> Hmmm, that's not great for set args:
> 
> (gdb) set args --command=myscript

That one could be special-cased.

Re: Strangeness in set command

[Doug Evans]

On Tue, Apr 8, 2008 at 11:56 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>  > From: Andrew STUBBS <andrew.stubbs@st.com>
>  > Eli Zaretskii wrote:
>  > > Or maybe, if the text after "set " has a `=' character in it, we
>  > > should ask whether the user really meant "set variable".  IOW, refuse
>  > > to obey this shortcut, even if it's unambiguous.
>  > >
>  >
>  > Hmmm, that's not great for set args:
>  >
>  > (gdb) set args --command=myscript
>
>  That one could be special-cased.

There's also prompt, env, and others.  Maybe the thing to do is key
off of var_string, etc., except that one can pass expressions for
integer/boolean vars.  Does the command parser know in time what it's
working with?

Re: Strangeness in set command

[Michael Snyder]

On Tue, 2008-04-08 at 11:57 +0100, Andrew STUBBS wrote:
> Eli Zaretskii wrote:
> >> From: Michael Snyder <msnyder@specifix.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Andreas Schwab <schwab@suse.de>,  gdb@sources.redhat.com
> >> Date: Mon, 07 Apr 2008 12:05:59 -0700
> >>
> >> The problem is that "so long as it is not ambiguous"
> >> is dicy, and changes over time as we add new subcommands
> >> to "set".
> >>
> >> The shortcut is probably one of those "seemed like a 
> >> good idea at the time" things, but now it's established
> >> and we're stuck with it.
> >>
> >> It would probably be a good idea if, every time we parse
> >> a "set" command, we try to match it with BOTH a variable
> >> AND a subcommand, and if there is ambiguity we say so
> >> explicitly.
> > 
> > Or maybe, if the text after "set " has a `=' character in it, we
> > should ask whether the user really meant "set variable".  IOW, refuse
> > to obey this shortcut, even if it's unambiguous.
> > 
> 
> Hmmm, that's not great for set args:
> 
> (gdb) set args --command=myscript

Well, ok, you could parse the first token (in this case "args"),
and then look for an = following it.  But you could have expressions
where the assignment operator wouldn't be the first token, eg:
  set ax->by = 12 or
  set *pc = 42

While not dismissing this idea, what about my first proposal of
parsing the args first as an expression, and second as a subcommand, 
and issuing an error if both parses succeed?

Re: Strangeness in set command

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@specifix.com> writes:

Michael> The shortcut is probably one of those "seemed like a 
Michael> good idea at the time" things, but now it's established
Michael> and we're stuck with it.

It seems to me that changing "set x = expr" from valid to invalid
would be painful -- but it would be a one-time pain, and it would not
cause surprises.

Tom

Re: Strangeness in set command

[Michael Snyder]

On Tue, 2008-04-08 at 18:34 -0600, Tom Tromey wrote:
> >>>>> "Michael" == Michael Snyder <msnyder@specifix.com> writes:
> 
> Michael> The shortcut is probably one of those "seemed like a 
> Michael> good idea at the time" things, but now it's established
> Michael> and we're stuck with it.
> 
> It seems to me that changing "set x = expr" from valid to invalid
> would be painful -- but it would be a one-time pain, and it would not
> cause surprises.

We could always try it and see if anybody screams...
;-)