On Sat, 28 May 2011, Francis Galiegue wrote:
> In Amanda, I have stumbled upon this function:
>
> ----
> int
> search_fstab(
> char * name,
> generic_fsent_t * fsent,
> int check_dev)
> {
> #ifdef IGNORE_FSTAB
> /* There is no real mount table so this will always fail and
> * * we are using GNU tar so we can just return here.
> * */
> (void)name; /* Quiet unused parameter warning */
> (void)fsent; /* Quiet unused parameter warning */
> (void)check_dev; /* Quiet unused parameter warning */
> return 0;
> #else
> /*
> * Things, but of no importance to the matter at hand
> */
> #endif /* !IGNORE_FSTAB */
> }
> ----
>
> I have reduced the file to this:
>
> ----
> int
> search_fstab(char *name, generic_fsent_t *fsent, int check_dev)
> {
> (void)name; /* Quiet unused parameter warning */
> (void)fsent; /* Quiet unused parameter warning */
> (void)check_dev; /* Quiet unused parameter warning */
> return 0;
> }
> ----
>
> and tried this patch, with the intent to find and report such
> di{rty,sgusting} hacks - not to mention that this same "(void)" hack
> is even embedded in some macros:
>
> ----
> @r@
> identifier f, dummy;
> type t;
> position p1, p2;
> @@
>
> f(...,
> t dummy@p1)
> {
> ...
> (void) dummy@p2;
> ...
> }
r should be an exists rule, and the ... should be <... ...>.
There is no problem about t. It matches struct foo *** just as well
as struct foo.
The problem is in the collection of interesting tokens from the semantic
patch, that is used to detect which files to process. I will fix it, but
the most immediate solution is to use the option -disable_worth_trying_opt
to disable the optimization that is causing it to ignore your file.
julia
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "UGLY HACK: see %s and %s, file %s, this should just go away" %
> (p1[0].line, p2[0].line, p1[0].file)
> ----
>
> But... No match. I know my SmPL file is incorrect. For instance, in
> its current form, t defines a type and not a pointer to a type. How do
> I abstract that away?
>
> Out of desperation, in order to have a match, I reduced the C sample to that:
>
> ---
> int
> search_fstab(int check_dev)
> {
> (void) check_dev; /* Quiet unused parameter warning */
> return 0;
> }
> ---
>
> And tried applying that:
>
> ---
> @r@
> identifier f, dummy;
> position p1, p2;
> type t;
> @@
>
> f(t dummy@p1)
> {
> ...
> (void) dummy@p2;
> ...
> }
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "UGLY HACK: see %s and %s, file %s, this should just go away" %
> (p1[0].line, p2[0].line, p1[0].file)
> ---
>
> Still no go! However, I do have a match with that:
>
> ----
> @r@
> identifier f, dummy;
> position p1, p2;
> @@
>
> f(int dummy@p1)
> {
> ...
> (void) dummy@p2;
> ...
> }
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "UGLY HACK: see %s and %s, file %s, this should just go away" %
> (p1[0].line, p2[0].line, p1[0].file)
> ----
>
> That is a pretty specific case... So, what do I get wrong? In order:
>
> * how can I abstract the type away from single argument functions?
> * and then, how can I generalize to all arguments of a function, not
> only single argument functions?
>
> --
> Francis Galiegue, [email protected]
> "It seems obvious [...] that at least some 'business intelligence'
> tools invest so much intelligence on the business side that they have
> nothing left for generating SQL queries" (Stéphane Faroult, in "The
> Art of SQL", ISBN 0-596-00894-5)
> _______________________________________________
> 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)
