At Tue, 12 Aug 2014 09:25:49 +0800,
Ruoyu wrote:
>
>
> On 2014年08月11日 21:45, Hitoshi Mitake wrote:
> > At Mon, 11 Aug 2014 18:11:44 +0800,
> > Ruoyu wrote:
> >> Nothing wrong with fixing it, alhough I don't know exactly
> >> what will be happened if not patching it.
> >>
> >> Signed-off-by: Ruoyu <lian...@ucweb.com>
> >> ---
> >> sheep/vdi.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/sheep/vdi.c b/sheep/vdi.c
> >> index 05cae7b..77dc253 100644
> >> --- a/sheep/vdi.c
> >> +++ b/sheep/vdi.c
> >> @@ -372,11 +372,12 @@ static bool add_new_participant(struct
> >> vdi_state_entry *entry,
> >> return true;
> >> }
> >>
> >> - idx = entry->nr_participants++;
> >> + idx = entry->nr_participants;
> >> memcpy(&entry->participants[idx], owner, sizeof(*owner));
> >> entry->participants_state[idx] =
> >> is_modified(entry) ?
> >> SHARED_LOCK_STATE_INVALIDATED : SHARED_LOCK_STATE_SHARED;
> >> + entry->nr_participants++;
> > I think this patch doesn't change the function. Does this fixes a bug?
> It fixes a logical error. Otherwise, there should be a hole in the array
> if new participant is added.
> For example,
>
> // supposed entry->nr_participants is 2;
> idx = entry->nr_participants++;
> // idx is 3 now;
No, idx is 2 in this case. Specification of C guarantees it. e.g.
#include <stdio.h>
int main(void)
{
int n = 2, m;
m = n++;
printf("n: %d, m: %d\n", n, m);
return 0;
}
if you execute the above program, you can see an output:
n: 3, m: 2
If the expression of increment is put before the incremented variable,
the assigned variable will be equal to the incremented result.
Thanks,
Hitoshi
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
