All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Kyle Evans <kevans@freebsd.org>, Greg Kurz <groug@kaod.org>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Warner Losh <imp@bsdimp.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 3/5] gdbstub: Use fixed-size array in GdbCmdParseEntry instead of pointer
Date: Thu, 06 May 2021 16:15:38 +0100	[thread overview]
Message-ID: <874kffopsn.fsf@linaro.org> (raw)
In-Reply-To: <42044899-6704-7d33-0a73-58fd00adc7ca@redhat.com>


Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 5/6/21 2:01 PM, Alex Bennée wrote:
>> 
>> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
>> 
>>> GdbCmdParseEntry should have enough room with 20 chars for the command
>>> string, and 8 for the schema. Add the GDB_CMD_PARSE_ENTRY_CMD_SIZE and
>>> GDB_CMD_PARSE_ENTRY_SCHEMA_SIZE definitions.
>>>
>>> Do not use pointer to string of unknown length, but array of fixed
>>> size. Having constant size will help use to remove the alloca() call
>>> in process_string_cmd() in the next commit.
>> 
>> I don't understand how this helps. The alloca is being used for an array
>> of GdbCmdVariant so why do we want to enlarge the size of the parse
>> table entries?
>
> This patch is crap indeed. I'll post another one with more sense.

Looking at the logic I wonder it's just better turning params into a
GArray and let glib deal with the sizing for us? It's not like one or
two entries breaks the bank on temporary memory allocation.

>
> Sorry about this,
>
> Phil.


-- 
Alex Bennée


  reply	other threads:[~2021-05-06 15:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 17:00 [PATCH 0/5] misc: Replace alloca() by g_malloc() Philippe Mathieu-Daudé
2021-05-05 17:00 ` [PATCH 1/5] bsd-user/syscall: Replace alloca() by g_new() Philippe Mathieu-Daudé
2021-05-05 17:00 ` [PATCH 2/5] gdbstub: Constify GdbCmdParseEntry Philippe Mathieu-Daudé
2021-05-06 11:50   ` Alex Bennée
2021-05-05 17:00 ` [PATCH 3/5] gdbstub: Use fixed-size array in GdbCmdParseEntry instead of pointer Philippe Mathieu-Daudé
2021-05-06 12:01   ` Alex Bennée
2021-05-06 12:39     ` Philippe Mathieu-Daudé
2021-05-06 15:15       ` Alex Bennée [this message]
2021-05-05 17:00 ` [PATCH 4/5] gdbstub: Replace alloca() by g_new() Philippe Mathieu-Daudé
2021-05-06 16:07   ` [ALT PATCH] gdbstub: Replace GdbCmdContext with plain g_array() Alex Bennée
2021-05-05 17:00 ` [PATCH 5/5] target/ppc/kvm: Replace alloca() by g_malloc() Philippe Mathieu-Daudé
2021-05-05 17:00   ` Philippe Mathieu-Daudé
2021-05-06  2:18   ` David Gibson
2021-05-06  2:18     ` David Gibson
2021-05-06  8:41   ` Greg Kurz
2021-05-06  8:41     ` Greg Kurz
2021-05-06 13:09     ` Philippe Mathieu-Daudé
2021-05-06 13:09       ` Philippe Mathieu-Daudé

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=874kffopsn.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=imp@bsdimp.com \
    --cc=kevans@freebsd.org \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.