[SSSD] [INI] Patches for ding-libs: Merging config sections, handling metadata, remaining Coverity issues...

Dmitri Pal dpal at redhat.com
Tue Mar 20 13:01:35 UTC 2012


On 03/20/2012 08:41 AM, Stephen Gallagher wrote:
> I'd like to know what you think it "hides", though.

There are two reasons that I have in mind.
1) When you add a new structure member you add it for purpose so it
should be initialized to a proper value. In many cases it is 0 but is
some cases it is not. Then you usually add code to do something with
this member (otherwise why you added it in the first place). If you
memset() the whole struct the value is already initialized and if you
forgot to set it to something you would have to spend long time to
figure out what is going on in testing. If you do not memset valgrind
will immediately find that you are using uninitialized value and point
you to the right place helping you to set the proper initial value. This
implies that valgrind is routinely executed which is the case in my dev
practice.
2) Structure can not be aligned so it will be padded. If then you try to
do some operations with the whole blob of data like print it with
debug() function you will access the uninitialized memory. This is not
good and generally you can't assume that the padding will be done in a
same way on different platforms so accessing uninitialized data will be
caught. If you memset you will be able to dump this data but it might be
meaningless as the layout might change from platform to platform.

These are weak arguments but they force the developer to be honest and
thorough so I think it is the "defensive programming" technique. But I
do not force anyone to agree with me. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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






More information about the sssd-devel mailing list