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

Ondrej Kos okos at redhat.com
Thu Nov 1 09:22:44 UTC 2012


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.
>
>> Thanks
>>
>> Ondrej
>>
>
>


-- 
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech

phone: +420-532-294-558
cell:  +420-736-417-909
ext:   82-62558
loc:   1013 Brno 1 office
irc:   okos @ #brno



More information about the sssd-devel mailing list