$argc variable

$argc variable

[Andrew STUBBS]

Hi,

There was a proposal here:
http://sources.redhat.com/ml/gdb-patches/2005-04/msg00055.html

Has anything come of it? I can't find anything in cli-script.c.

This is a feature I would very much like to see. SuperH/ST has had a 
very similar feature for quite some time now (long before the above 
proposal) in which $argc is a proper convenience variable.

I would submit our version, but I feel that the above is a better 
approach (implementation details aside) - it does not suffer from 
problems with recursion.

Is there any chance of resurrecting this idea?

Thanks

Andrew Stubbs

Re: $argc variable

[Dan Nicolaescu]

Andrew STUBBS <andrew.stubbs@st.com> writes:

  > Hi,
  > 
  > There was a proposal here:
  > http://sources.redhat.com/ml/gdb-patches/2005-04/msg00055.html
  > 
  > Has anything come of it? I can't find anything in cli-script.c.

As a user I can say that such a feature would be great to have.
For example both GCC and Emacs define a function "pr" to print
internal data structures. To use it you have to do:

p VARIABLE
pr 

Instead with this feature you could still do the same, but also:
pr VARIABLE
or 
pr VARIABLE1 VARIABLE2 VARIABLE3

Just my 2 cents

Thanks
                --dan

Re: $argc variable

[Daniel Jacobowitz]

On Thu, Nov 03, 2005 at 01:08:34PM +0000, Andrew STUBBS wrote:
> Hi,
> 
> There was a proposal here:
> http://sources.redhat.com/ml/gdb-patches/2005-04/msg00055.html
> 
> Has anything come of it? I can't find anything in cli-script.c.
> 
> This is a feature I would very much like to see. SuperH/ST has had a 
> very similar feature for quite some time now (long before the above 
> proposal) in which $argc is a proper convenience variable.
> 
> I would submit our version, but I feel that the above is a better 
> approach (implementation details aside) - it does not suffer from 
> problems with recursion.
> 
> Is there any chance of resurrecting this idea?

It's still in the review queue.  I didn't like the implementation, but
I haven't had time to come up with a better one.  If you feel like
helping...  You'll notice no one else responded at the time when I
asked for comments.

In general I don't like new additions to the CLI.  But it seems like
real scripting is still at least one major release away, so I am
open to suggestions.  Let's do it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: $argc variable

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> It's still in the review queue.  I didn't like the implementation, but
> I haven't had time to come up with a better one.  If you feel like
> helping...  You'll notice no one else responded at the time when I
> asked for comments.

What, specifically, did you not like about the implementation?

I'd be happy to have a bash at it, but it would be easier to avoid the 
same problems if I knew what they were.

Thanks

Andrew Stubbs

Re: $argc variable

[Daniel Jacobowitz]

On Mon, Nov 07, 2005 at 11:09:29AM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >It's still in the review queue.  I didn't like the implementation, but
> >I haven't had time to come up with a better one.  If you feel like
> >helping...  You'll notice no one else responded at the time when I
> >asked for comments.
> 
> What, specifically, did you not like about the implementation?
> 
> I'd be happy to have a bash at it, but it would be easier to avoid the 
> same problems if I knew what they were.

Mostly, the coding style was very un-GNU.  I also got the feeling that
there were better ways to do a lot of the string parsing, but I really
didn't spend much time looking at it (since I figured reimplementing
would be simpler in this case than FSF assignment).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: $argc variable

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Daniel Jacobowitz wrote:
> Mostly, the coding style was very un-GNU.  I also got the feeling that
> there were better ways to do a lot of the string parsing, but I really
> didn't spend much time looking at it (since I figured reimplementing
> would be simpler in this case than FSF assignment).

I'm not sure exactly what I have to do to avoid being "un-GNU", but 
here's my attempt at the same problem. I don't think the string parsing 
can be made any simpler.

In the documentation I changed a '@var' to '@code' because @var makes it 
upper case in the info and I thought that misleading. I also added a 
missing 'end' to the existing example.

OK?

Andrew Stubbs

[-- Attachment #2: argc.patch --]
[-- Type: text/plain, Size: 4212 bytes --]

2005-11-08  Andrew Stubbs  <andrew.stubbs@st.com>

	* cli/cli-script.c: Include gdb_assert.h.
	(locate_arg): Detect $argc.
	(insert_args): Substitute $argc.
	* Makefile.in (cli-script.o): Add dependency on gdb_assert.h.

doc/
	* gdb.texinfo (User-defined commands): Add $argc. Add missing 'end'.
	Change @var{$arg0 to @code{$arg0 to keep case right.

Index: src/gdb/cli/cli-script.c
===================================================================
--- src.orig/gdb/cli/cli-script.c	2005-11-08 12:39:37.000000000 +0000
+++ src/gdb/cli/cli-script.c	2005-11-08 12:40:10.000000000 +0000
@@ -33,6 +33,7 @@
 #include "cli/cli-cmds.h"
 #include "cli/cli-decode.h"
 #include "cli/cli-script.h"
+#include "gdb_assert.h"
 
 /* Prototypes for local functions */
 
@@ -572,7 +573,8 @@ locate_arg (char *p)
 {
   while ((p = strchr (p, '$')))
     {
-      if (strncmp (p, "$arg", 4) == 0 && isdigit (p[4]))
+      if (strncmp (p, "$arg", 4) == 0
+	  && (isdigit (p[4]) || p[4] == 'c'))
 	return p;
       p++;
     }
@@ -596,12 +598,20 @@ insert_args (char *line)
       len += p - line;
       i = p[4] - '0';
 
-      if (i >= user_args->count)
+      if (p[4] == 'c')
+	{
+	  /* $argc.  Number will be <=10.  */
+	  len += user_args->count == 10 ? 2 : 1;
+	}
+      else if (i >= user_args->count)
 	{
 	  error (_("Missing argument %d in user function."), i);
 	  return NULL;
 	}
-      len += user_args->a[i].len;
+      else
+	{
+	  len += user_args->a[i].len;
+	}
       line = p + 5;
     }
 
@@ -625,13 +635,27 @@ insert_args (char *line)
 
       memcpy (new_line, line, p - line);
       new_line += p - line;
-      i = p[4] - '0';
 
-      len = user_args->a[i].len;
-      if (len)
+      if (p[4] == 'c')
+	{
+	  gdb_assert (user_args->count >= 0 && user_args->count <= 10);
+	  if (user_args->count == 10)
+	    {
+	      *(new_line++) = '1';
+	      *(new_line++) = '0';
+	    }
+	  else
+	    *(new_line++) = user_args->count + '0';
+	}
+      else
 	{
-	  memcpy (new_line, user_args->a[i].arg, len);
-	  new_line += len;
+	  i = p[4] - '0';
+	  len = user_args->a[i].len;
+	  if (len)
+	  {
+	    memcpy (new_line, user_args->a[i].arg, len);
+	    new_line += len;
+	  }
 	}
       line = p + 5;
     }
Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo	2005-11-08 12:39:40.000000000 +0000
+++ src/gdb/doc/gdb.texinfo	2005-11-08 12:40:11.000000000 +0000
@@ -15660,11 +15660,12 @@ A @dfn{user-defined command} is a sequen
 which you assign a new name as a command.  This is done with the
 @code{define} command.  User commands may accept up to 10 arguments
 separated by whitespace.  Arguments are accessed within the user command
-via @var{$arg0@dots{}$arg9}.  A trivial example:
+via @code{$arg0@dots{}$arg9}.  A trivial example:
 
 @smallexample
 define adder
   print $arg0 + $arg1 + $arg2
+end
 @end smallexample
 
 @noindent
@@ -15680,6 +15681,21 @@ its three arguments.  Note the arguments
 reference variables, use complex expressions, or even perform inferior
 functions calls.
 
+@kindex $argc
+In addition, @code{$argc} may be used to find out how many arguments have
+been passed.  This expands to a number in the range 0@dots{}10.
+
+@smallexample
+define adder
+  if $argc == 2
+    print $arg0 + $arg1
+  end
+  if $argc == 3
+    print $arg0 + $arg1 + $arg2
+  end
+end
+@end smallexample
+
 @table @code
 
 @kindex define
Index: src/gdb/Makefile.in
===================================================================
--- src.orig/gdb/Makefile.in	2005-11-08 12:39:40.000000000 +0000
+++ src/gdb/Makefile.in	2005-11-08 12:40:11.000000000 +0000
@@ -2807,7 +2807,7 @@ cli-logging.o: $(srcdir)/cli/cli-logging
 	$(CC) -c $(INTERNAL_CFLAGS) $(srcdir)/cli/cli-logging.c
 cli-script.o: $(srcdir)/cli/cli-script.c $(defs_h) $(value_h) $(language_h) \
 	$(ui_out_h) $(gdb_string_h) $(exceptions_h) $(top_h) $(cli_cmds_h) \
-	$(cli_decode_h) $(cli_script_h)
+	$(cli_decode_h) $(cli_script_h) $(gdb_assert_h)
 	$(CC) -c $(INTERNAL_CFLAGS) $(srcdir)/cli/cli-script.c
 cli-setshow.o: $(srcdir)/cli/cli-setshow.c $(defs_h) $(readline_tilde_h) \
 	$(value_h) $(gdb_string_h) $(ui_out_h) $(cli_decode_h) $(cli_cmds_h) \

Re: $argc variable

[Eli Zaretskii]

> Date: Tue, 08 Nov 2005 12:48:20 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: GDB List <gdb@sources.redhat.com>

Btw, Andrew, why do you post patches to gdb@sources.redhat.com, rather
than to gdb-patches@ ?  The latter is the right place.

> In the documentation I changed a '@var' to '@code' because @var makes it 
> upper case in the info and I thought that misleading.

Upper case is not the problem: makeinfo produces an uppercase word
from @var since time immemoriam, so anyone who's used to read Info
manuals is already used to that.

The problem here is that it's simply wrong to use @var in this case,
because $arg0 etc. are literal strings, to be used verbatim in the
actual script, not placeholders that stand for something else.  So
your change is correct, although for the wrong reasons. ;-)

> -via @var{$arg0@dots{}$arg9}.  A trivial example:

However, there _is_ something wrong here: the $ part should be outside
@var, since it's a literal character:

  via @code{$@var{arg0}@dots{}$@var{arg9}}.

> +via @code{$arg0@dots{}$arg9}.  A trivial example:
>  
>  @smallexample
>  define adder
>    print $arg0 + $arg1 + $arg2
> +end
>  @end smallexample

In the example, I would suggest to use something other than arg0 etc.,
to avoid confusion with arg0..arg9 as placeholders in the paragraph
where you wanted to remove @var.

> +@kindex $argc

I'd replace this with "@cindex arguments for user-defined function".

Other than that, the documentation patch is okay with me.  Thanks.

Re: $argc variable

[Andrew STUBBS]

Eli Zaretskii wrote:
> Btw, Andrew, why do you post patches to gdb@sources.redhat.com, rather
> than to gdb-patches@ ?  The latter is the right place.

I post patches to gdb-patches@ and other messages to gdb@ which, in this 
case, has a patch as a follow up. Should I switch list as soon as I have 
a patch? That seems a little disconnected to me, but I see your point. I 
originally posted the new options I had to gdb@ because I thought they 
might be a little more controversial - I also called them RFC.

>>In the documentation I changed a '@var' to '@code' because @var makes it 
>>upper case in the info and I thought that misleading.
> 
> 
> Upper case is not the problem: makeinfo produces an uppercase word
> from @var since time immemoriam, so anyone who's used to read Info
> manuals is already used to that.

I would respectfully suggest that manuals should be written for those 
that do NOT know what they are doing. However, as you say, using 
upper-case for non-literal text is fine and I understand that and if 
users try to type it then there are bigger problems than case.

> The problem here is that it's simply wrong to use @var in this case,
> because $arg0 etc. are literal strings, to be used verbatim in the
> actual script, not placeholders that stand for something else.  So
> your change is correct, although for the wrong reasons. ;-)

Well, I would have been happy with the wrong mark-up if the end 
type-face had been right - it just depends on your point of view ;)

>>-via @var{$arg0@dots{}$arg9}.  A trivial example:
> 
> 
> However, there _is_ something wrong here: the $ part should be outside
> @var, since it's a literal character:
> 
>   via @code{$@var{arg0}@dots{}$@var{arg9}}.

Err, haven't you just put back the @var, and therefore upper case, that 
we just agreed shouldn't be there?

>>+via @code{$arg0@dots{}$arg9}.  A trivial example:
>> 
>> @smallexample
>> define adder
>>   print $arg0 + $arg1 + $arg2
>>+end
>> @end smallexample
> 
> 
> In the example, I would suggest to use something other than arg0 etc.,
> to avoid confusion with arg0..arg9 as placeholders in the paragraph
> where you wanted to remove @var.

But this is an example of how to use $arg0 ?!?!? Also, it isn't my 
example, I only added the 'end'.

> 
> 
>>+@kindex $argc
> 
> 
> I'd replace this with "@cindex arguments for user-defined function".

Replace or augment? I considered adding a kindex for $arg0...$arg9.

I agree that a concept should be added, but how about:

@cindex user-defined functions, argument passing

Just a thought.

> 
> Other than that, the documentation patch is okay with me.  Thanks.

Great, I'll wait for judgement on the code then.

Thanks

Andrew Stubbs

Re: $argc variable

[Eli Zaretskii]

> Date: Wed, 09 Nov 2005 11:12:38 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: gdb@sources.redhat.com
> 
> Eli Zaretskii wrote:
> > Btw, Andrew, why do you post patches to gdb@sources.redhat.com, rather
> > than to gdb-patches@ ?  The latter is the right place.
> 
> I post patches to gdb-patches@ and other messages to gdb@ which, in this 
> case, has a patch as a follow up. Should I switch list as soon as I have 
> a patch? That seems a little disconnected to me, but I see your point. I 
> originally posted the new options I had to gdb@ because I thought they 
> might be a little more controversial - I also called them RFC.

Patches should go to gdb-patches.  If you want to discuss possible
changes, start the discussion on gdb-patches.

> > Upper case is not the problem: makeinfo produces an uppercase word
> > from @var since time immemoriam, so anyone who's used to read Info
> > manuals is already used to that.
> 
> I would respectfully suggest that manuals should be written for those 
> that do NOT know what they are doing.

A user who reads an Info manual for the first time should read the
Info introduction (which is the first menu item of the global DIR
menu).  There's more to Info conventions than just this one.

The reason for the choice of @var translation is that Info is for text
terminals which don't support slanted typefaces (which is how @var
looks in print and in HTML).

> > The problem here is that it's simply wrong to use @var in this case,
> > because $arg0 etc. are literal strings, to be used verbatim in the
> > actual script, not placeholders that stand for something else.  So
> > your change is correct, although for the wrong reasons. ;-)
> 
> Well, I would have been happy with the wrong mark-up if the end 
> type-face had been right - it just depends on your point of view ;)

My point of view is to use right Texinfo conventions ;-)

> >>-via @var{$arg0@dots{}$arg9}.  A trivial example:
> > 
> > 
> > However, there _is_ something wrong here: the $ part should be outside
> > @var, since it's a literal character:
> > 
> >   via @code{$@var{arg0}@dots{}$@var{arg9}}.
> 
> Err, haven't you just put back the @var, and therefore upper case, that 
> we just agreed shouldn't be there?

Sorry, I started to write different text, then realized I was in
error, but failed to erase the wrong text.  Please re-read my message
as it _should_ have been written, below.  Sorry for the confusion.

> >>+via @code{$arg0@dots{}$arg9}.  A trivial example:
> >> 
> >> @smallexample
> >> define adder
> >>   print $arg0 + $arg1 + $arg2
> >>+end
> >> @end smallexample
> > 
> > 
> > In the example, I would suggest to use something other than arg0 etc.,
> > to avoid confusion with arg0..arg9 as placeholders in the paragraph
> > where you wanted to remove @var.
> 
> But this is an example of how to use $arg0 ?!?!?

See above: this text shouldn't have been sent.

> >>+@kindex $argc
> > 
> > 
> > I'd replace this with "@cindex arguments for user-defined function".
> 
> Replace or augment?

Replace.

> I considered adding a kindex for $arg0...$arg9.

This isn't useful: having several index entries that begin with
identical substrings and point to the same page in the manual has only
one effect: it makes the index larger.

> I agree that a concept should be added, but how about:
> 
> @cindex user-defined functions, argument passing

This is good.

Here's what I _intended_ to send:

    Date: Wed, 09 Nov 2005 01:19:28 +0200
    From: Eli Zaretskii <eliz@gnu.org>
    To: Andrew STUBBS <andrew.stubbs@st.com>
    CC: gdb@sources.redhat.com
    Subject: Re: $argc variable

    > Date: Tue, 08 Nov 2005 12:48:20 +0000
    > From: Andrew STUBBS <andrew.stubbs@st.com>
    > Cc: GDB List <gdb@sources.redhat.com>

    Btw, Andrew, why do you post patches to gdb@sources.redhat.com, rather
    than to gdb-patches@ ?  The latter is the right place.

    > In the documentation I changed a '@var' to '@code' because @var makes it 
    > upper case in the info and I thought that misleading.

    Upper case is not the problem: makeinfo produces an uppercase word
    from @var since time immemoriam, so anyone who's used to read Info
    manuals is already used to that.

    The problem here is that it's simply wrong to use @var in this case,
    because $arg0 etc. are literal strings, to be used verbatim in the
    actual script, not placeholders that stand for something else.  So
    your change is correct, although for the wrong reasons. ;-)

    > +@kindex $argc

    I'd replace this with "@cindex arguments for user-defined function".

    Other than that, the documentation patch is okay with me.  Thanks.

Re: $argc variable

[Andrew STUBBS]

Eli Zaretskii wrote:
> Sorry, I started to write different text, then realized I was in
> error, but failed to erase the wrong text.  Please re-read my message
> as it _should_ have been written, below.  Sorry for the confusion.

Ok, thanks, this makes much more sense. I shall change the index and the 
reason in the changelog for the @var change.

Now, what about the actual code? Anyone?

Andrew Stubbs

Re: $argc variable

[Daniel Jacobowitz]

On Thu, Nov 10, 2005 at 10:08:22AM +0000, Andrew STUBBS wrote:
> Eli Zaretskii wrote:
> >Sorry, I started to write different text, then realized I was in
> >error, but failed to erase the wrong text.  Please re-read my message
> >as it _should_ have been written, below.  Sorry for the confusion.
> 
> Ok, thanks, this makes much more sense. I shall change the index and the 
> reason in the changelog for the @var change.
> 
> Now, what about the actual code? Anyone?

It looks OK to me.  Could you post the revised documentation (to
gdb-patches, please) so that we can make sure that Eli and you did
converge?  I couldn't quite follow your earlier conversation.

-- 
Daniel Jacobowitz
CodeSourcery, LLC