From: Tom Tromey <tom@tromey.com>
To: Tom de Vries <tdevries@suse.de>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix struct expression regression
Date: Fri, 04 Dec 2020 15:13:40 -0700 [thread overview]
Message-ID: <875z5h43u3.fsf@tromey.com> (raw)
In-Reply-To: <1c9be726-8b1b-cb05-16b0-078342cbcb23@suse.de> (Tom de Vries's message of "Fri, 4 Dec 2020 14:49:55 +0100")
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> memmove (exp->elts + new_op_end, exp->elts + orig_op_end,
Tom> EXP_ELEM_TO_BYTES (orig_nelts - orig_op_end));
Tom> ...
Tom> at which point I realized that in theory extra_elts could be negative,
Tom> in which case the resize might reduce the amount of memory for
Tom> exp->elts, after which memmove would read out of bounds. Not sure if
Tom> that is realistic or not.
It seems to me that this must be a pre-existing latent bug, because the
new patch just reuses the existing rewriting logic -- it just changes it
to work in-place.
I suspect the bug can't occur in practice, because
replace_operator_with_call is only called for certain opcodes, and I
think none of these can be as long as the replacement:
case OP_VAR_VALUE:
[...]
case BINOP_ADD:
case BINOP_SUB:
case BINOP_MUL:
case BINOP_DIV:
case BINOP_REM:
case BINOP_MOD:
case BINOP_CONCAT:
case BINOP_BITWISE_AND:
case BINOP_BITWISE_IOR:
case BINOP_BITWISE_XOR:
case BINOP_EQUAL:
case BINOP_NOTEQUAL:
case BINOP_LESS:
case BINOP_GTR:
case BINOP_LEQ:
case BINOP_GEQ:
case BINOP_EXP:
case UNOP_NEG:
case UNOP_PLUS:
case UNOP_LOGICAL_NOT:
case UNOP_ABS:
Tom
next prev parent reply other threads:[~2020-12-04 22:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 0:41 Tom Tromey
2020-12-04 13:49 ` Tom de Vries
2020-12-04 22:13 ` Tom Tromey [this message]
2020-12-05 8:32 ` [gdb/ada] Handle shrink resize in replace_operator_with_call Tom de Vries
2020-12-07 4:36 ` Tom Tromey
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=875z5h43u3.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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).