Well, just to avoid a possibility any long-run apps repeat FcFini() and FcInit() and see overflow in the future. I know it takes so long long time to arrive; in fact in even busy loop it may takes about 90 days in my dev env from estimation. but just thought it may be good to get rid of such possibly anyway. though I should consider to add a kinda fc_atomic_int_set() but I was lazy to do that ;) <div class="gmail_quote">2015/05/23 1:06 "Behdad Esfahbod" <<a href="mailto:behdad.esfahbod@gmail.com">behdad.esfahbod@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15-05-22 04:53 AM, Akira TAGOH wrote: > + fc_atomic_ptr_cmpexch (&next_id, ot->id + 1, FC_MAX_BASE_OBJECT + FC_EXT_OBJ_INDEX + 1); This won't work, as next_id is an integer and fc_atomic_ptr_cmpexch works on a pointer. I suggest changing next_id to long, and then forget about overflow completely. How did you arrive at this patch? I don't think we care about overflow, even if next_id was 16 bits only! b </blockquote></div>