On Mon, Apr 9, 2012 at 6:43 AM, Julia Lawall <[email protected]> wrote: > For the whole kernel, I get over 32,000 potential added calls. Perhaps > there is some way to better constrain the cases where it should be used? > > julia
OOH, THANK YOU for that script. Now that I see it, I understand it - at least a little bit. You are a ninja !! 32k is *alot* and I see youve already constrained it to static defs. Devs sometimes add comments about keeping A,B in sync if you change... but the form of comments surely varies, and IIUC, cocci cant look at comments. I'll try it out, inspect the results, and see if I can find more constraints. thanks again. > > > On Mon, 9 Apr 2012, Jim Cromie wrote: > >> On Sun, Apr 8, 2012 at 11:30 PM, Julia Lawall <[email protected]> >> wrote: >>> >>> >>> >>> On Sun, 8 Apr 2012, Jim Cromie wrote: >>> >>>> hi all, >>>> >>>> I recently posted the following patch to LKML. >>>> ISTM that coccinelle is a reasonable way to find cases >>>> where the macro would be useful and beneficial, >>>> but detecting those situations is quite different than the usual cases. >>>> >>>> What do you think ? >>> >>> >>> >>> I'm not sure what kinds of cases should be considered? What does the >>> first >>> argument to the macro represent? How do you know when you want >>> ARRAY_SIZE >>> and when you want sizeof? >> >> >> hi Julia, >> >> ARRAY_SIZE is always a safe answer. >> I added the sizeof examples for a simple explanation, >> but it only works when the element sizes are guaranteed >> to match. That isnt a safe assumption for structs, >> which may get fields added later. >> >> the name arg is arbitrary - it only distinguishes between >> multiple uses of the macro in the same scope. >> Its a suffix on the expanded var name: BUILD_BUG_DECL_##name. >> Referencing the expanded name should be considered bad, >> the intent is *only* to break the compile if one array is longer >> than the other. >> >> The arrays to be checked are typically file-scope >> static constant tables, but it would be good to handle >> compares of file-static vs function static arrays. >> And conceivably 2 tables defined in separate files. >> >> I gave one example case in my forwarded email, >> I trimmed the rest of that email, example (for b43) is below. >> >> I dont know if its a good example, generally the confidence >> for any report would be medium to low, enough to prompt a look >> by the maintainer. >> >>> >>> >>>> It is perhaps simpler to think about one-file-at-a-time, >>>> that would cover 95% of uses. >>> >>> >>> >>> Coccinelle normally works one file at a time. >>> >> >> Ah but it does do API transformations, where >> function and its users are in separate files. >> IIUC, thats its main purpose and strength. >> >> I was just "thinking aloud", looking for ways >> to simplify the problem. >> >> >>> julia >>> >>>> thanks >>>> ~jimc >>>> >> >> >>>> For example (perhaps a bad one, I only eyeballed the tables >>>> themselves): in drivers/net/wireless/b43/tables_lpphy.c, these 2 >>>> tables are the same size. Should that be enforced ?? >>>> >>>> static const u16 lpphy_rev0_ofdm_cck_gain_table[] = {...} >>>> static const u16 lpphy_rev1_ofdm_cck_gain_table[] = {...} >>>> >> >> for this particular case, sizeof would work, since both arrays >> are the same type. Since coccinelle is good with type matching, >> I guess it comes for free, but ARRAY_SIZE would be correct, >> and there is no run-time cost here; only fixed arrays are >> checked by the compiler. My demo code tried testing 2 arrays >> passed into a function, and checked inside - although gcc >> can apparently optimize across function calls when it knows >> all the callers (1 in that case), it didnt like the macro used >> inside the fn. That would be a case to explicitly skip. _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
