[zeromq-dev] Github 'stable' workflow (was Re: [PATCH] prefix tree bug)
Martin Lucina
mato at kotelna.sk
Mon Aug 30 08:32:01 CEST 2010
Martin,
sustrik at 250bpm.com said:
> Yes. Thanks! I haven't accounted for the corner case where a node in the
> trie has 256 subnodes.
>
> Mato, what's the process for committing fixes that are to be eventually
> backported to the stable?
Now that I actually understand Git better, it's best for us to follow the
workflow used by the Git people themselves:
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
For 0MQ we can do without the 'next' and 'pu' branches, for now.
As you've asked me to translate this into set of exact commands for you to
follow, please wait for that, until then it would be best if you did not
push to Github 'master' anything that should go into a stable release.
Can't you mark those patches in your mail client with a "hold for stable"
label or something?
Alternatively, if you don't want to wait for me, follow the following steps
(which is what I did):
1) Watch Linus talk on Git: http://www.youtube.com/watch?v=4XpnKHJAok8
2) Read anything about Git workflows, especially
http://kerneltrap.org/Linux/Git_Management
3) Repeat the above until it goes "Click" :-)
Sorry I can't be more explicit right now, give me another day, busy with
clients ...
-mato
>
> Martin
>
>> Prior to this patch prefix_tree asserted for me with this test program
>>
>> #include <prefix_tree.hpp>
>> #include <iostream>
>> #include <stdio.h>
>>
>> int main()
>> {
>>
>> zmq::prefix_tree_t m;
>>
>> for (int i = 0; i < 512; i++)
>> {
>> printf("%08x\n",i);
>> m.add((unsigned char*)&i,sizeof(int));
>>
>> }
>> int count = 0;
>> for (int i = 0; i < 512; i++)
>> {
>> printf("%08x\n",i);
>> count += m.check((unsigned char*)&i,sizeof(int));
>> }
>> printf("%d\n",count);
>> }
>>
>> this is because as it adds the 255th element at a node it attempts to
>> calculate the count member var which is an unsigned char via
>> count = (255 -0) + 1;
>> and pass the result to realloc. Unfortunately the result is zero and
>> realloc returns null;
>> the prefix_tree asserts.
>>
>> I have fixed it by making the count an unsigned short.
>>
>> The fix works for me and the program above returns 512 as expected and
>> valgrind doesnt gripe either, but there may be a better way.
>>
>> I'm submitting it under the MIT/X11 license should it be deemed acceptable.
>>
>> Jon
>>
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
More information about the zeromq-dev
mailing list