Comment 12 for bug 1244662

shoot. I thought I had attached a cleaned up version of that.
I tested your newer diff, and i believe it still to be wrong.

My confusion stems from not knowing how partx_{add,del,resize}_partition functions understand their 'int partno' argument.

Given the partition table layout created by the following input to sfdisk -uS $DEV:
0,0,0
4096,2048,L
0,0,0
2048,2048,L

sfdisk --durmp output shows that as:
$ sudo sfdisk -uS --dump /dev/vdb
# partition table of /dev/vdb
unit: sectors
/dev/vdb1 : start= 0, size= 0, Id= 0
/dev/vdb2 : start= 4096, size= 2048, Id=83
/dev/vdb3 : start= 0, size= 0, Id= 0
/dev/vdb4 : start= 2048, size= 2048, Id=83

There are 2 different numbering schemes being mixed here.
a.) the order of blkid_struct_partlist.parts array as returned by get_partlist
  To my understanding, this is the order as seen in the partition table.
ie:
  vdb2: 1
  vdb4: 0

b.) the "human order" that is input to partx.
  vdb2: 2
  vdb4: 4

The code as it is right now (and with your suggested fix) I believe makes an invalid assumption about the relationship between A and B.

I'm fairly sure that partx_{add,del,resize}_partition assume 'b' for the partno parameter.

My fix was to only deal with 'b' in the loop by adding the helper function that got the partition 'b' with input 'a'. See my cleaned up patch for example.