[SSSD] [INI] Remove code that allows duplicate sections

Dmitri Pal dpal at redhat.com
Thu Nov 1 15:01:44 UTC 2012


On 11/01/2012 05:22 AM, Ondrej Kos wrote:
> On 10/31/2012 10:50 PM, Dmitri Pal wrote:
>> On 10/31/2012 08:35 AM, Ondrej Kos wrote:
>>> On 10/18/2012 05:02 AM, Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> After previous set of patches have been committed I started working on
>>>> the last remaining piece - the merge functionality.
>>>>
>>>> Re-reading the code I started some time ago I realized that at the
>>>> time
>>>> I left the question of whether the config object should allow
>>>> partitioned section or not was still open.
>>>>
>>>> Consider an example of the config file:
>>>>
>>>> [foo]
>>>> x=1
>>>>
>>>> [bar]
>>>> y=2
>>>>
>>>> [foo]
>>>> z=3
>>>>
>>>> Here we have an example of the case when the section is segmented
>>>> or if
>>>> you look from another POW there are dup sections. So at first I
>>>> thought
>>>> that it is OK to parse the file as is and have the internal config
>>>> object have two sections with same name. But after some deep
>>>> thinking I
>>>> realized that it is a bad idea and creates a lot of unnecessary
>>>> complexity. So patch removes this code. This paves the way to a more
>>>> simple code in the merge function as we can assume that there are
>>>> no dup
>>>> sections in the objects being merged.
>>>>
>>>> I also noticed that doc build is spitting warnings so I opened a
>>>> separate ticket about it. That would be my next patch.
>>>> https://fedorahosted.org/sssd/ticket/1587
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sssd-devel mailing list
>>>> sssd-devel at lists.fedorahosted.org
>>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>>>
>>>
>>> Ack on the patch, one question though, do you have any coding style
>>> template against which I could check this? It's obviously different
>>> from the one used in the sssd.
>>>
>>
>> Ding-libs have been forked from SSSD some time ago.
>> The coding style is generally the same however the development style
>> (not defined in the coding style) is quite different.
>> For example I do not like godo and prefer checking errors and reporting
>> them in place: sort of action-check-report-clean-return paradigm.
>> I also try to allow tracing out of the library while it is developed but
>> it is a compile time debugging not a runtime debugging.
>>
>> Where do you see the deviation from the standard?
>> If I am formatting something incorrectly please let me know.
> I originally thought that it was just an mistake, but then i found
> that you're using the if-else statement a little bit differently than
> stated in the coding guide (thus used in sssd)
>
> You're using:
>
>     if (condition) {
>         /* do some work */
>     }
>     else {
>         /* do some other work */
>     }
>
> While the coding guide suggests use of:
>
>     if (condition) {
>         /* do some work */
>     } else {
>         /* do some other work */
>     }
>
> I was looking to the code now and didn't find anything else.

Hm, this is something that I have been doing from the beginning. I guess
it was just a mistake on my side. But now the code is in the first style.
Is it worth switching to the correct code style for the new code without
fixing the old one? Is it worth at all?

I opened the ticket to track it
https://fedorahosted.org/sssd/ticket/1617

>>
>>> Thanks
>>>
>>> Ondrej
>>>
>>
>>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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






More information about the sssd-devel mailing list