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
