Re: [PATCH V3 1/4] Rework value part of name-value pairs

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

 



On Mon, Oct 24, 2011 at 12:07:27PM -0400, Stefan Berger wrote:
> NWFilters can be provided name-value pairs using the following
> XML notiation:
> 
>       <filterref filter='xyz'>
>         <parameter name='PORT' value='80'/>
>         <parameter name='VAL' value='abc'/>
>       </filterref>
> 
> The internal representation currently is so that a name is stored as a
> string and the value as well. This patch now addresses the value part of it
> and introduces a data structure for storing a value either as a simple
> value or as an array for later support of lists (provided in python-like
> notation ( [a,b,c] ).
> 
> This patch adjusts all code that was handling the values in hash tables
> and makes it use the new data type.
> 
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx>
> 
> ---
>  src/conf/domain_conf.c                    |    2 
>  src/conf/nwfilter_params.c                |  288 ++++++++++++++++++++++++++++--
>  src/conf/nwfilter_params.h                |   38 +++
>  src/libvirt_private.syms                  |    3 
>  src/nwfilter/nwfilter_ebiptables_driver.c |   15 +
>  src/nwfilter/nwfilter_gentech_driver.c    |   27 ++
>  src/nwfilter/nwfilter_learnipaddr.c       |   13 +
>  7 files changed, 365 insertions(+), 21 deletions(-)

> +bool
> +virNWFilterVarValueDelValue(virNWFilterVarValuePtr val, const char *value)
> +{
> +    unsigned int i;
> +
> +    switch (val->valType) {
> +    case NWFILTER_VALUE_TYPE_SIMPLE:
> +        return false;
> +
> +    case NWFILTER_VALUE_TYPE_ARRAY:
> +        for (i = 0; i < val->u.array.nValues; i++) {
> +            if (STREQ(value, val->u.array.values[i])) {
> +                VIR_FREE(val->u.array.values[i]);
> +                val->u.array.nValues--;
> +                val->u.array.values[i] =
> +                                val->u.array.values[val->u.array.nValues];
> +                return true;

This doesn't look right. Consider

   | A | B | C | D | E |

And you're deleting 'B'. This code will result in a list

   | A | C | C | D |

because you're only shuffling down the immediate neighbour
of the element being deleted, rather than all following
elements.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]