[libvirt] [PATCH 1/4] virStorageVol: avoid PATH_MAX-sized array
Matthias Bolte
matthias.bolte at googlemail.com
Wed Jun 22 22:55:25 UTC 2011
2011/6/22 Eric Blake <eblake at redhat.com>:
> POSIX allows implementations where PATH_MAX is undefined, leading
> to compilation error. Not to mention that even if it is defined,
> it is often wasteful in relation to the amount of data being stored.
>
> All clients of vol->key were audited, and found not to care about
> whether key is static or dynamic, except for these offenders:
>
> * src/datatypes.h (struct _virStorageVol): Manage key dynamically.
> * src/datatypes.c (virReleaseStorageVol): Free key.
> (virGetStorageVol): Copy key.
> ---
>
> I'm also adding a 'make syntax-check' rule in gnulib to catch this
> from being a problem in the future:
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/27259
>
> src/datatypes.c | 8 +++++---
> src/datatypes.h | 5 ++---
> 2 files changed, 7 insertions(+), 6 deletions(-)
> @@ -254,8 +254,7 @@ struct _virStorageVol {
> virConnectPtr conn; /* pointer back to the connection */
> char *pool; /* Pool name of owner */
> char *name; /* the storage vol external name */
> - /* XXX currently abusing path for this. Ought not to be so evil */
> - char key[PATH_MAX]; /* unique key for storage vol */
> + char *key; /* unique key for storage vol */
> };
I think that the comment was referring to the some storage backends
using the path of a file as the key instead of some other form of key.
So the comment may still be valid (but only for specific backend) and
was not related to PATH_MAX here. As it's definitely wrong to have it
in this general place I think it's okay to remove it.
ACK.
--
Matthias Bolte
http://photron.blogspot.com
More information about the libvir-list
mailing list