From: Peter Maydell <peter.maydell@linaro.org>
To: Chetan <chetan4windows@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: Better alternative to strncpy in QEMU.
Date: Mon, 12 Apr 2021 14:19:58 +0100 [thread overview]
Message-ID: <CAFEAcA_8ZsHwa+vxz99q52FUP4n7QDTLWpEEh2n_v-Ujiwdu_g@mail.gmail.com> (raw)
In-Reply-To: <CAPPKfOGwK7JDfHaTT-e4Z7bFkYoWu=dHvF-fT+QdqJhnwCLvOw@mail.gmail.com>
On Sun, 11 Apr 2021 at 14:52, Chetan <chetan4windows@gmail.com> wrote:
> char *qemu_strncpy(char destination[], char source[], size_t destination_size)
> {
> /* Looping through the array and copying the characters from
> * source to destination.
> */
> for (int i = 0; i < strlen(source); i++) {
> destination[i] = source[i];
>
> /* Check if value of i is equal to the second last index
> * of destination array and if condition is true, mark last
> * index as NULL and break from the loop.
> */
> if (i == (destination_size - 2)) {
> destination[destination_size - 1] = '\0';
> break;
> }
> }
> return destination;
> }
This implementation is "accidentally quadratic", because it
calls strlen(source) every time through the loop, and thus
copying an N byte string will read N*N bytes of memory. (The
compiler can't pull the "strlen(source)" call up out of the loop
because it can't guarantee that source and destination don't
overlap.)
I think this is a good illustration of why we probably don't want
to roll our own string operation functions if we can avoid it
(ie without having a clear view of why we are improving on either
what libc or glib offer us).
thanks
-- PMM
next prev parent reply other threads:[~2021-04-12 13:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-11 13:50 Better alternative to strncpy in QEMU Chetan
2021-04-12 4:51 ` Thomas Huth
2021-04-13 7:32 ` Paolo Bonzini
2021-04-12 13:19 ` Peter Maydell [this message]
2021-04-13 2:50 ` Chetan
[not found] <mailman.36964.1618210428.30242.qemu-devel@nongnu.org>
2021-04-12 12:48 ` Bruno Piazera Larsen
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=CAFEAcA_8ZsHwa+vxz99q52FUP4n7QDTLWpEEh2n_v-Ujiwdu_g@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=chetan4windows@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@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 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 NNTP newsgroup(s).