Maybe it doesn't have the required type information? You can try
spatch -type_c yourfile.c
and see whether it puts types on the expression of interest.
Apparently not, I have pastbin the output: http://pastebin.com/ESriRGhT
I get that, among other things:
bad: p_sys->i_timescale = p_mvhd->data.p_mvhd->i_timescale;
OK, the problem is not the lack of type information, but that it is not
parsing the code at all. What it doesn't like is:
bad: #ifdef WORDS_BIGENDIAN
bad: p_ftyp->data.p_ftyp->i_major_brand
bad: #else
BAD:!!!!! p_ftyp->data.p_ftyp->i_major_brand >> 24
bad: #endif
I'm not sure why it doesn't like this. Normally it should be able to code
with ifdefs, ignoring the #else if needed. The parse error is about
p_ftyp. Perhaps it has decided that this is a type name, because of
misparsing something else. You could try just extracting this function
and seeing if the parsing is more successful. If it still fails, try
replacing the ifdef branches by something more innocuous, such as a
constant.
julia
The lack of type information generally occurs because of a header file that
is not being taken into account. The -all_includes option will try to find
all of the header files that are included directly in the file. The
-recursive_includes will additionally find header files that are included by
others. You may also need to give some include paths with -I. Neither of
these are the default because parsing header files is very time consuming.
You'd have to check about how you can get coccigrep to pass arguments on to
spatch.
A priori it's not the problem, p_sys is a "demux_sys_t" which is
defined in the same file.
Best Regards,
--
Frédéric
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
