[linux-dvb] patch - descrambling on stream level

Manu Abraham abraham.manu at gmail.com
Thu Oct 20 11:51:19 CEST 2005


Philip Prindeville wrote:

>>>
>>>
>>> Regarding:
>>>
>>> +       struct descriptor *p_en50221_streams_desc =
>>> +               (struct descriptor *) malloc(sizeof (struct 
>>> descriptor) * p_streams->streams_desc_count);
>>>
>>> malloc() returns a "void *", which is an untyped pointer.  It 
>>> doesn't need
>>> to be cast.  Also:
>>>
>>
>> Right.
>>
>>>    p = malloc(sizeof(*p));
>>>
>>> is a lot more clear than:
>>>
>>>    p = malloc(sizeof(struct descriptor))
>>>
>>> since you don't have to flip back and confirm that "p" is of type
>>> "struct descriptor".  Same applies whether you are allocating a
>>> single element or an array of them.
>>
>>
>>
>>
>>
>> This is not quite right. On LKML, this has been proven not advisable.
>> You can see a lengthy discussion of this on LKML with a thread like this
>>
>> http://marc.theaimsgroup.com/?t=112703827100001&r=1&w=2
>
>
>
> I skimmed through that, and the basic arguments are:
>
> (1) it's not easy to grep -- my answer to that is get real tools,
> like cscope, rather than twisting your programming habits to
> conform to inadequate tools.
>
> (2) the contents of a structure change more often that the type
> of structure a variable refers to -- not always true.  If you are
> cutting & pasting similar routines that deal with structures that
> are similar but vary only in a couple of additional elements,
> then this isn't true...  which actually happens a lot when you're
> doing protocol programming in middleware (and which I spent
> the last 5 years doing, so I saw it happen a lot...)
>
> (3) that if the type of structure changes, then you're more likely
> to leave members of the structure uninitialized -- this argument
> was so twisted it left my head hurting...  this is more of an argument
> for using an abstract function for allocating and initializing structures
> than having client functions call malloc() directly, which thereby
> gives you a single place to add/remove new member handling in the
> initialization.
>
> Most of the discussion is about the evils of using temporary structures
> when doing literal construction for an RHS, and the inherent evils of
> the memcpy() that ensues...
>
> Not really pertinent.
>

There were other arguments also on that ..
http://marc.theaimsgroup.com/?l=linux-kernel&m=112706121111345&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=112724751307927&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=112724557730973&w=2

Anyway, i would find ,
sizeof (struct foo) to be more clear than sizeof (*foo). But that is a 
personal argument. Other than that, it doesn't convey the right meaning 
too, what are we checking the sizeof ? The sizeof the pointer or the 
object ?

Since we have most of the code like that,(sizeof (struct foo)) and most 
of the people following a specific coding style, it would be nice to 
follow one standard coding style rather than introduce another coding style.


Manu




More information about the linux-dvb mailing list