qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/3] block/rbd: encryption nit fixes


From: Ilya Dryomov
Subject: Re: [PATCH v4 1/3] block/rbd: encryption nit fixes
Date: Thu, 12 Jan 2023 15:26:56 +0100

On Thu, Jan 12, 2023 at 1:35 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Sun, Nov 20, 2022 at 04:28:34AM -0600, Or Ozeri wrote:
> > Add const modifier to passphrases,
> > and remove redundant stack variable passphrase_len.
> >
> > Signed-off-by: Or Ozeri <oro@il.ibm.com>
> > ---
> >  block/rbd.c | 24 ++++++++++--------------
> >  1 file changed, 10 insertions(+), 14 deletions(-)
> >
> > diff --git a/block/rbd.c b/block/rbd.c
> > index f826410f40..e575105e6d 100644
> > --- a/block/rbd.c
> > +++ b/block/rbd.c
> > @@ -330,7 +330,7 @@ static int qemu_rbd_set_keypairs(rados_t cluster, const 
> > char *keypairs_json,
> >  #ifdef LIBRBD_SUPPORTS_ENCRYPTION
> >  static int qemu_rbd_convert_luks_options(
> >          RbdEncryptionOptionsLUKSBase *luks_opts,
> > -        char **passphrase,
> > +        const char **passphrase,
> >          size_t *passphrase_len,
> >          Error **errp)
> >  {
> > @@ -341,7 +341,7 @@ static int qemu_rbd_convert_luks_options(
> >  static int qemu_rbd_convert_luks_create_options(
> >          RbdEncryptionCreateOptionsLUKSBase *luks_opts,
> >          rbd_encryption_algorithm_t *alg,
> > -        char **passphrase,
> > +        const char **passphrase,
> >          size_t *passphrase_len,
> >          Error **errp)
> >  {
> > @@ -384,8 +384,7 @@ static int qemu_rbd_encryption_format(rbd_image_t image,
> >                                        Error **errp)
> >  {
> >      int r = 0;
> > -    g_autofree char *passphrase = NULL;
> > -    size_t passphrase_len;
> > +    g_autofree const char *passphrase = NULL;
>
> This looks wierd.  If it is as const string, why are
> we free'ing it ?  Either want g_autofree, or const,
> but not both.

Just curious, is it a requirement imposed by g_autofree?  Otherwise
pointer constness and pointee lifetime are completely orthogonal and
freeing (or, in this case, wanting to auto-free) an object referred to
by a const pointer seems perfectly fine to me.

Thanks,

                Ilya



reply via email to

[Prev in Thread] Current Thread [Next in Thread]