All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-devel@nongnu.org, "Brad Smith" <brad@comstyle.com>,
	qemu-trivial@nongnu.org
Subject: Re: [PATCH] ui/console-vc: Silence warning about sprintf() on OpenBSD
Date: Tue, 15 Oct 2024 09:08:53 +0100	[thread overview]
Message-ID: <87ttddaiui.fsf@draig.linaro.org> (raw)
In-Reply-To: <67e2cb19-8de6-4ebf-ab4f-ae13b3de134d@tls.msk.ru> (Michael Tokarev's message of "Mon, 14 Oct 2024 22:50:44 +0300")

Michael Tokarev <mjt@tls.msk.ru> writes:

> On 14.10.2024 18:15, Daniel P. Berrangé wrote:
>
>> These two lines are the only place in the code that uses the
>>     char response[40];
>> so even better than switching to snprintf, how about just taking
>> buffer size out of the picture:
>>    g_autofree *response =
>>        g_strdup_printf("\033[%d;%dR",
>>                        (s->y_base + s->y) % s->total_height + 1,
>>                        s->x + 1);
>>    vc_respond_str(vc, response);
>
> What's the reason to perform memory allocation in trivial places
> like this?  If we're worrying about possible buffer size issue,
> maybe asprintf() is a better alternative for such small things?
> Fragmenting heap memory for no reason seems too much overkill.
> But I'm old-scool, so.. :)

I doubt the allocate/free pair will cause much fragmentation but it
doesn't look like we are in any hot path here. Anyway snprintf is
certainly better than sprintf so:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

>
> /mjt

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  reply	other threads:[~2024-10-15  8:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 15:10 [PATCH] ui/console-vc: Silence warning about sprintf() on OpenBSD Thomas Huth
2024-10-14 15:15 ` Daniel P. Berrangé
2024-10-14 19:50   ` Michael Tokarev
2024-10-15  8:08     ` Alex Bennée [this message]
2024-10-15  8:14     ` Daniel P. Berrangé
2024-10-15 11:28       ` Thomas Huth
2024-10-15  6:34 ` Marc-André Lureau

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=87ttddaiui.fsf@draig.linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=brad@comstyle.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=thuth@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 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.