Re: [PATCH] Handle comments in the C expression parser

Re: [PATCH] Handle comments in the C expression parser

[Michael Elizabeth Chastain]

Hi Daniel,

> It has to, it's the lexer. It's doing the tokenizing. 

Fair enough.  What happens here:

  (gdb) print /* multi line
  comment */ 1 + 2

I bet it gives "unterminated comment" (as soon as you fix the code).
This is a deviation from C, but it doesn't really bother me.

> Not in particular, I added it when someone suggested that, and wanted
> to get it into the tree before it became a casualty of bitrot on one
> of my trees ...

I know the feeling.

If I saw something useful about /* ... */ I'd be in favor, but right
now, I'd just as soon see it scrapped.

Michael

Re: [PATCH] Handle comments in the C expression parser

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Hi Daniel,
> 
> > It has to, it's the lexer. It's doing the tokenizing. 
> 
> Fair enough.  What happens here:
> 
>   (gdb) print /* multi line
>   comment */ 1 + 2
> 
> I bet it gives "unterminated comment" (as soon as you fix the code).
> This is a deviation from C, but it doesn't really bother me.

It shouldn't give that error, you should get an error as soon as you
hit enter after line.
Remember, we don't handle real multiline expressions. Adding a line
continuation character is doing just that, continuing the previous
line.

The expression lexer/parsers get handed (by the command that is
specified) whatever part of the line the various commands don't eat
themselves, AFAIK. 
How am I so sure?
Well, we have no way, in our lexers, to get more input from the
user, or a stream. It only has the lexptr. It does no non-preprocessed (IE not
already gotten from the user and stored somewhere) input consuming of
it's own (it can't, or else, for example readline history, among a
billion other things, would fail for that input, since readline
wouldn't know about it). 


Think of comments as ignored quoted strings with different start and
end chars. I know, it sounds like i'm saying "think of a car as a
bicycle with a steel frame, four wheels, an engine, etc", but they
really aren't dissimilar.
They are handled the same way in the lexer, except we don't care about
what's inside them, so the logic is a *lot* simpler.


> 
> > Not in particular, I added it when someone suggested that, and wanted
> > to get it into the tree before it became a casualty of bitrot on one
> > of my trees ...
> 
> I know the feeling.
> 
> If I saw something useful about /* ... */ I'd be in favor, but right
> now, I'd just as soon see it scrapped.

Okeydokey, fine by me.

It's in the archives if it comes up later, at least.

On to better things.
:)

> 
> Michael

Re: [PATCH] Handle comments in the C expression parser

[Michael Elizabeth Chastain]

Gaah ... mailer glitch.

I was going to say: I'll snarf the patch from the gcc mailing list
archive, apply it to my own tree, and see how the C++ test results
come out.

Michael

Re: [PATCH] Handle comments in the C expression parser

[Michael Elizabeth Chastain]

From gdb-patches-return-6004-chastain=cygnus.com@sources.redhat.com Tue Feb 13 22:25 PST 2001
Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm
Sender: gdb-patches-owner@sources.redhat.com
X-Authentication-Warning: dynamic-addr-83-177.resnet.rochester.edu: dberlin set sender to dberlin@redhat.com using -f
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Handle comments in the C expression parser
From: Daniel Berlin <dberlin@redhat.com>
Date: 14 Feb 2001 01:24:59 -0500
Lines: 38
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Thalia)

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> > It shouldn't give that error, you should get an error as soon as you
> > hit enter after line.
> 
> Err, yeah.
> 
>   (gdb) print /* multi line
>   error: unterminated comment
> 
> ... that is what I am thinking.
> 
> > Think of comments as ignored quoted strings with different start and
> > end chars.
> 
> And different \ convention.  I'm too tired to figure out how gdb
> handles \ in '...' and "..." strings.
> 

It calls "parse_escape", and lets it handle it. If parse_escape
returns -1 or something, it gives you an escape error. Otherwise, it
continues eating about it's very way.


> > On to better things.
> > :)
> 
> Oooh, oooh, can we get a new demangler with "unsigned int",
> "void", "char *", and "foo &" ?
> 
> That would make 5 or 6 people happy.
> 
I'm still waiting for approval, i'll ping again.

I've been busy abstracting the other differences that pop up, into a
C++ abi framework (IE struct cp_abi_ops).
--Dan
> Michael

Re: [PATCH] Handle comments in the C expression parser

[Michael Elizabeth Chastain]

> It shouldn't give that error, you should get an error as soon as you
> hit enter after line.

Err, yeah.

  (gdb) print /* multi line
  error: unterminated comment

... that is what I am thinking.

> Think of comments as ignored quoted strings with different start and
> end chars.

And different \ convention.  I'm too tired to figure out how gdb
handles \ in '...' and "..." strings.

> On to better things.
> :)

Oooh, oooh, can we get a new demangler with "unsigned int",
"void", "char *", and "foo &" ?

That would make 5 or 6 people happy.

Michael

Re: [PATCH] Handle comments in the C expression parser

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> > It shouldn't give that error, you should get an error as soon as you
> > hit enter after line.
> 
> Err, yeah.
> 
>   (gdb) print /* multi line
>   error: unterminated comment
> 
> ... that is what I am thinking.
> 
> > Think of comments as ignored quoted strings with different start and
> > end chars.
> 
> And different \ convention.  I'm too tired to figure out how gdb
> handles \ in '...' and "..." strings.
> 

It calls "parse_escape", and lets it handle it. If parse_escape
returns -1 or something, it gives you an escape error. Otherwise, it
continues eating about it's very way.


> > On to better things.
> > :)
> 
> Oooh, oooh, can we get a new demangler with "unsigned int",
> "void", "char *", and "foo &" ?
> 
> That would make 5 or 6 people happy.
> 
I'm still waiting for approval, i'll ping again.

I've been busy abstracting the other differences that pop up, into a
C++ abi framework (IE struct cp_abi_ops).
--Dan
> Michael

Re: [PATCH] Handle comments in the C expression parser

[Michael Elizabeth Chastain]

Hi Daniel,

! 	  while (*lexptr != '*')
! 	    lexptr++;

What happens if the user opens a comment with '/*' and does not close it?
It looks like lexptr will go off into the weeds.

Also I do not know if lexptr has access to the whole input in contiguous
memory, or if it gets fed chunks of characters as they arrive.
I can do stuff like this in gdb:

  (gdb) print 1 + \
  2
  $1 = 3

On the design level, I am not opposed to adding in C style comments
in a C parser.  But I am skeptical about the planned use for:

  break 'Foo::Foo /* base */ (int)'

... which is what I presume you are working towards.

I thought about this name scheme some more:

  Foo::Foo
  Foo::Foo$Base

You remark that Foo::Foo$Base is not a constructor, because
"Foo$Base" != "Foo".  I think that is actually a useful property.
Foo$Base really *is not* a constructor.

If gdb wanted to construct an object in a region of memory, it would call
one of the Foo::Foo constructors.  It would never call Foo::Foo$Base.
And the same with Foo::~Foo versus Foo::~Foo$Base.

If there are multiple overloaded Foo::Foo's, the Foo::Foo$Base's
should not join in overload resolution.

I admit there are some ways that Foo::Foo$Base is like a constructor.
It does contain a copy of all the code that the user wrote for a constructor.
Its object code has source line number records that point back into
the C++ source code for the constructor.  But I think it's useful to
model it as *not a constructor*, because it does not have the interface
(the programming contract) of a constructor.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

Re: [PATCH] Handle comments in the C expression parser

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Hi Daniel,
> 
> ! 	  while (*lexptr != '*')
> ! 	    lexptr++;
> 
> What happens if the user opens a comment with '/*' and does not close it?
> It looks like lexptr will go off into the weeds.
Yes, I assumed they would close it.
I'll fix it.
it's a simple fix anyway, i'd rather someone review the patch assuming
that bug will be fixed (change it to while (*lexptr && *lexptr !=
'*')).


> 
> Also I do not know if lexptr has access to the whole input in contiguous
> memory, or if it gets fed chunks of characters as they arrive.

It has to, it's the lexer. It's doing the tokenizing. 

The parser will see and exp, then ask for the next token. We only say
"/" if it's not a /*. Otherwise, we say it's the first thing after the
comment.

That was the only use of "/" in the entire parser, (exp '/' exp). So
this is safe.



> I can do stuff like this in gdb:
> 
>   (gdb) print 1 + \
>   2
>   $1 = 3
> 
(gdb) print 1 + \
/* this is a test */ \
3
$1 = 4
(gdb)
(gdb) print 1 + \
/* this is \
a test \
of \
comments \
*/ 3
$2 = 4
(gdb)

:)


Push up, after typing that in, and see what your line got transformed into.

> On the design level, I am not opposed to adding in C style comments
> in a C parser.  But I am skeptical about the planned use for:
> 
>   break 'Foo::Foo /* base */ (int)'
> 
> ... which is what I presume you are working towards.

Not in particular, I added it when someone suggested that, and wanted
to get it into the tree before it became a casualty of bitrot on one
of my trees, like the ternary search tree stuff i have that helps
demangled minsym lookups, and demangled name lookups, and memory
usage, a *ton*.

:)

[PATCH] Handle comments in the C expression parser

[Daniel Berlin]

This patch adds C-style comment handling to the expression parser.

That way, we can add comments to output of various places, and still
be able to paste it back in.
(gdb) p 5 /* / */ / 3
$1 = 1
(gdb) p 5 /* / */ / 3 */* 333333 blah */ 2
$2 = 2
(gdb) p 5 /* / */ / 3 */* 333333 blah */ 2
$3 = 2
(gdb) p 5 /* / */ / 3 */* 333333 blah */ 2
$4 = 2
(gdb) p 5 /* / */ / 3 */* 333333 blah *// 2
A parse error in expression, near ` 2'.
(gdb) p 5 /* / */ / 3 */* 333333 blah *// 2
A parse error in expression, near ` 2'.
(gdb) p 5 /* / */ / 3 */* 333333 blah */2/ 2
$5 = 1
(gdb)


(The parse errors are because, if you look closely, it's really 5 / 3
* / 2, so the parse error is correct. )

2001-02-13  Daniel Berlin  <dberlin@redhat.com>

        * c-exp.y : Handle C style comments in expression parser,
        ignoring them.

Re: [PATCH] Handle comments in the C expression parser

[Eli Zaretskii]

On 13 Feb 2001, Daniel Berlin wrote:

> This patch adds C-style comment handling to the expression parser.

If this is accepted, please consider sending a short description of the 
feature for gdb.texinfo.

Thanks.