[SSSD] [PATCHES] Collection, Ref Array, ELAPI

Dmitri Pal dpal at redhat.com
Thu Jan 21 04:43:24 UTC 2010


Dmitri Pal wrote:
> Stephen Gallagher wrote:
>   
>> On 12/23/2009 03:59 PM, Dmitri Pal wrote:
>>     
>>> Hi,
>>>       
>>> * I am not resending the COLLECTION patch. Ticket #350 has been open to
>>> foster further discussion about the issue.
>>> * The refarray is now made common and the attached (or should I say
>>> attacked? :-) ) patch addresses ALL issues that have been brought up.
>>>       
>>> The ELAPI patch will be sent later. I need to update it to factor in the
>>> change in the location of the ref-array.
>>> Also I checked that the patch will get much smaller if I ask it to track
>>> deletes or moves/copies.
>>> It actually gets twice smaller.
>>>       
>>> It is really not that big (read bad :-) ). It has about 2000-3000 lines
>>> of new code thanks for async processing (not that I wanted it to happen
>>> :-) )...
>>> But all the rest is just due to the cleanup. For example the module
>>> elapi_dispatcher had too many functions that were not related to
>>> dispatcher so they got moved around to other modules.
>>> Same with elapi_sink, elapi_log etc.
>>> Now the code is much better arranged in layers and objects.
>>>       
>>> Also the wiki is your helper in review. It has now the write up about
>>> ELAPI that I created before I submitted this patch last time.
>>>       
>>     
>>> Happy holidays!
>>> Talk to you next year!
>>>       
>>> Dmitri
>>>       
>> Nack.
>>
>> Line 282 should be:
>> printf("Element = %u\n", (unsigned int)ra->elsize);
>> Otherwise you're throwing a compilation warning:
>>
>> ../../../common/refarray/ref_array.c: In function ref_array_debug:
>> ../../../common/refarray/ref_array.c:282: warning: format %u expects
>> type unsigned int, but argument 2 has type size_t
>>
>>     
>
> Interesting. It does not produce this warning on my system...
> I made the change anyways though I have seen this issue before and then
> it went away.
> May be it was different part of code.
>
>
>   
>> ref_array_len is still completely broken. Now, instead of returning 0 on
>> error, you're returning 22. This is even worse.
>>
>> Please either use the approach I showed in an earlier email, or return 0
>> and set errno=EINVAL:
>>
>>     if (!ra) {
>>         TRACE_ERROR_STRING("Uninitialized argument.", "");
>>         errno=EINVAL;
>>         return 0;
>>     }
>>
>> This might be the better approach for you, since if the caller doesn't
>> care about an error, they can just ignore errno.
>>
>>
>>     
> Uhhhh. Good catch!
>
>
>   

Forgot to mention that the patch was attached.


>> Almost there. :)
>>
>>     
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-REFARRAY-New-referenced-array-object.patch
Type: text/x-patch
Size: 25294 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100120/b7344e79/attachment.bin>


More information about the sssd-devel mailing list