From: Keith Seitz <keiths@redhat.com>
To: "gdb-patches@sourceware.org ml" <gdb-patches@sourceware.org>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc]
Date: Thu, 17 Oct 2013 18:18:00 -0000 [thread overview]
Message-ID: <52602A08.4020705@redhat.com> (raw)
In-Reply-To: <m3vc0wg4yg.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]
On 10/16/2013 04:40 PM, Sergio Durigan Junior wrote:
> I had a brief chat with Keith, who updated me on this. According to
> him, there are many more places that need to be updated. He's already
> talking to Pierre about this, so probably my patch is not
> complete/correct. Thus, feel free to drop it if it is the case.
Yeah, my apologies. I *thought* I had a pascal compiler installed, but I
didn't. [Maybe I was thinking of Fortran?] In any case, my previous
patch to pascal_lex does some really nasty things, like assigning to
lexptr/stoken from an alloca'd block. Boo!
This patch fixes the regressions by doing what I should have done the
first time around: it changes pascal_lex to really take const input.
There are two little sections of code, though, which violate const-ness
of the input, and I've removed those, since they don't seem necessary.
[This is the two loops that deal with changing the case of `tokstart' --
which can easily be removed because we already have a temporary buffer
that is used for this.]
I could not think of any reasons why pascal_lex would need to change the
input. The only thing that came to mind was completion, and the behavior
for that is, as far as I can tell, identical to how 7.0, 7.3, 7.4, 7.5,
and 7.6 behave. [both case-sensitive 'on' and 'off']
[Perhaps Pierre knows? It was added here:
commit 458d424149528912ee72f6b9b9a2afd578a17715
Author: Pierre Muller <muller@ics.u-strasbg.fr>
Date: Fri Nov 9 09:46:40 2001 +0000
2001-11-06 Pierre Muller <muller@ics.u-strasbg.fr>
* p-exp.y (yylex): Only change case of expression if symbol is
found.
Also check for GPC standard name form.
]
In any case, IMO parsers should not be changing their input. If this
turns out to be necessary, we should extend the API to support it.
Comments?
Keith
ChangeLog
2013-10-17 Keith Seitz <keiths@redhat.com>
* p-exp.y (uptok): Make first parameter const.
(yylex): Make `tokstart' and `tokptr' const.
Don't copy the lexer input to a temporary buffer.
Make `p' const.
Remove const workaround ofr parse_escape.
Create a temporary buffer for a convenience variable instead
of doing in-place modification of the input.
If a match is found with a different case from the input,
do not change the input at all.
Use `tmp' to construct the resultant stoken instead of
`tokstart'.
[-- Attachment #2: p-exp_y-regressions.patch --]
[-- Type: text/x-patch, Size: 3864 bytes --]
diff --git a/gdb/p-exp.y b/gdb/p-exp.y
index de14cbb..8cb98c0 100644
--- a/gdb/p-exp.y
+++ b/gdb/p-exp.y
@@ -125,7 +125,7 @@ static int yylex (void);
void yyerror (char *);
-static char * uptok (char *, int);
+static char *uptok (const char *, int);
%}
/* Although the yacc "value" of an expression is not used,
@@ -1105,7 +1105,7 @@ static const struct token tokentab2[] =
/* Allocate uppercased var: */
/* make an uppercased copy of tokstart. */
static char *
-uptok (char *tokstart, int namelen)
+uptok (const char *tokstart, int namelen)
{
int i;
char *uptokstart = (char *)malloc(namelen+1);
@@ -1133,9 +1133,9 @@ yylex (void)
int c;
int namelen;
unsigned int i;
- char *tokstart;
+ const char *tokstart;
char *uptokstart;
- char *tokptr;
+ const char *tokptr;
int explen, tempbufindex;
static char *tempbuf;
static int tempbufsize;
@@ -1146,9 +1146,8 @@ yylex (void)
prev_lexptr = lexptr;
+ tokstart = lexptr;
explen = strlen (lexptr);
- tokstart = alloca (explen + 1);
- memcpy (tokstart, lexptr, explen + 1);
/* See if it is a special token of length 3. */
if (explen > 2)
@@ -1264,7 +1263,7 @@ yylex (void)
{
/* It's a number. */
int got_dot = 0, got_e = 0, toktype;
- char *p = tokstart;
+ const char *p = tokstart;
int hex = input_radix > 10;
if (c == '0' && (p[1] == 'x' || p[1] == 'X'))
@@ -1369,11 +1368,8 @@ yylex (void)
break;
case '\\':
{
- const char *s, *o;
-
- o = s = ++tokptr;
- c = parse_escape (parse_gdbarch, &s);
- *tokptr += s - o;
+ ++tokptr;
+ c = parse_escape (parse_gdbarch, &tokptr);
if (c == -1)
{
continue;
@@ -1511,17 +1507,17 @@ yylex (void)
if (*tokstart == '$')
{
- char c;
+ char *tmp;
+
/* $ is the normal prefix for pascal hexadecimal values
but this conflicts with the GDB use for debugger variables
so in expression to enter hexadecimal values
we still need to use C syntax with 0xff */
write_dollar_variable (yylval.sval);
- c = tokstart[namelen];
- tokstart[namelen] = 0;
- intvar = lookup_only_internalvar (++tokstart);
- --tokstart;
- tokstart[namelen] = c;
+ tmp = alloca (namelen + 1);
+ memcpy (tmp, tokstart, namelen);
+ tmp[namelen] = '\0';
+ intvar = lookup_only_internalvar (tmp + 1);
free (uptokstart);
return VARIABLE;
}
@@ -1561,12 +1557,6 @@ yylex (void)
else
sym = lookup_symbol (tmp, expression_context_block,
VAR_DOMAIN, &is_a_field_of_this);
- if (sym || is_a_field_of_this.type != NULL || is_a_field)
- for (i = 0; i <= namelen; i++)
- {
- if ((tokstart[i] >= 'a' && tokstart[i] <= 'z'))
- tokstart[i] -= ('a'-'A');
- }
}
/* Third chance Capitalized (as GPC does). */
if (!sym && is_a_field_of_this.type == NULL && !is_a_field)
@@ -1589,24 +1579,13 @@ yylex (void)
else
sym = lookup_symbol (tmp, expression_context_block,
VAR_DOMAIN, &is_a_field_of_this);
- if (sym || is_a_field_of_this.type != NULL || is_a_field)
- for (i = 0; i <= namelen; i++)
- {
- if (i == 0)
- {
- if ((tokstart[i] >= 'a' && tokstart[i] <= 'z'))
- tokstart[i] -= ('a'-'A');
- }
- else
- if ((tokstart[i] >= 'A' && tokstart[i] <= 'Z'))
- tokstart[i] -= ('A'-'a');
- }
}
if (is_a_field)
{
tempbuf = (char *) realloc (tempbuf, namelen + 1);
- strncpy (tempbuf, tokstart, namelen); tempbuf [namelen] = 0;
+ strncpy (tempbuf, tmp, namelen);
+ tempbuf [namelen] = 0;
yylval.sval.ptr = tempbuf;
yylval.sval.length = namelen;
free (uptokstart);
next prev parent reply other threads:[~2013-10-17 18:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 18:57 [RFA 4/4] Constify parse_linesepc Keith Seitz
2013-10-01 4:15 ` Sergio Durigan Junior
2013-10-01 20:16 ` Tom Tromey
2013-10-02 4:38 ` Keith Seitz
2013-10-16 9:57 ` Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc] Jan Kratochvil
2013-10-16 22:07 ` Sergio Durigan Junior
2013-10-16 23:40 ` Sergio Durigan Junior
2013-10-17 18:18 ` Keith Seitz [this message]
2013-10-17 20:52 ` Tom Tromey
2013-10-18 17:20 ` Jan Kratochvil
2013-10-18 19:09 ` [pascal patch] Use case_sensitive_off [Re: Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc]] Jan Kratochvil
2013-10-18 19:34 ` Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc] Jan Kratochvil
2013-10-20 13:17 ` Pierre Muller
2013-10-20 13:27 ` Jan Kratochvil
2013-10-29 16:39 ` Tom Tromey
2013-10-31 16:14 ` Pierre Muller
2013-11-13 20:43 ` Keith Seitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52602A08.4020705@redhat.com \
--to=keiths@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=sergiodj@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).