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
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)
