[linux-dvb] patch - descrambling on stream level
abraham.manu at gmail.com
Thu Oct 20 11:51:19 CEST 2005
Philip Prindeville wrote:
>>> + 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:
>>> 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
> 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
> 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 ..
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
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.
More information about the linux-dvb