regit / coccigrep Goto Github PK

I was working with the file "mp4.c" of VLC gitweb link

The following:

coccigrep -t demux_sys_t -a i_timescale -c -o set mp4.c

returns nothing, although line 476, you have this :

p_sys->i_timescale = p_mvhd->data.p_mvhd->i_timescale;

And even without the "-o set", this line isn't detected.

I've got latest coccigrep and coccinelle -1.0.0-rc9

This is strange because there is nothing unusual in the mismatched line...

I wanted to use coccigrep on nginx's source code, so I've checked out https://github.com/nginx/nginx. The following experiments is done on master (as of today 65ae8b31).

In src/http/ngx_http_variables.c there is:

static ngx_int_t
ngx_http_variable_request_method(ngx_http_request_t *r,
    ngx_http_variable_value_t *v, uintptr_t data)
{
    if (r->main->method_name.data) {
        v->len = r->main->method_name.len;
        v->valid = 1;
        v->no_cacheable = 0;
        v->not_found = 0;
        v->data = r->main->method_name.data;

I wanted to track the use of method_name, defined in ngx_http_request.h in the struct ngx_http_request_s type.
As we can see, the method_name is accessed through the main field of type ngx_http_request_t (source) within the struct ngx_http_request_s type.

One last thing to know, is that ngx_http_request_t is an alias to struct nginx_http_request_s (source).

I was expecting coccigrep -t 'ngx_http_request_t' -a method_name src/http/ngx_http_variables.c to return several lines, as shown in the code snippet.

Also, coccigrep -t ngx_http_request_t src/http/ngx_http_variables.c returns results, whereas coccigrep -t 'struct ngx_http_request_s' src/http/ (or even the more specific coccigrep -t 'struct ngx_http_request_s' src/http/ngx_http_variables.c src/http/ngx_http.h which contains the file where the typedef is defined) doesn't yield any result.

Are those bugs, or expected behaviours? Thanks!

It would be nice if macros were expanded before coccigrep process the files, but I can't think of a very convenient solution.

For a single file I would do something like:
grep -v "^#include" | cpp | coccigrep -t foo -a bar

But ideally the user shouldn't have to think about it. If someone has an idea...

If you have this file x.c:

int f1(Context *ctx)
{
  int y = ctx->member;
UNRESOLVED_MACRO
  return 0;
}

And then you run
coccigrep -t "Context" -a "member" x.c
you get no results.

Is this the expected behaviour? Is there anything that can be done to make coccigrep smarter about this?

# spatch -version
spatch version 1.0.0-rc9 with Python support and with PCRE support

I changed:

def get_spatch_version(self):
    cmd = [self.spatch] + [ '--version']

into:

def get_spatch_version(self):
    cmd = [self.spatch] + [ '-version']

to make it work, otherwise I get a python script error.

If we have the following code

struct test {
	unsigned long first;
	unsigned long second;
};

const static struct test const_struct = {
	.first = 42,
};

int func(struct test *test)
{
	test->first = 42;

	return 0;
}

int main()
{
	struct test new_struct = {
		.first = 14,
	};
	struct test other_struct;

	other_struct.first = 84;

	return 0;
}

Then, coccigrep -t "struct test" -a first -o set test.c only returns the first assignments in the code:

test.c:12 (struct test *test):		test->first = 42;
test.c:24 (struct test other_struct):		other_struct.first = 84;

However, all the ones done in the structures initialization are missing.

Not sure if its a bug or just me ;-) but when I do a grep for seq_file structure ...

# coccigrep -t seq_file fs/seq_file.c
# 

... on the kernel source tree, it should output something I presume.

# spatch -version
spatch version 1.0.0-rc9 with Python support and with PCRE support

I have default install from your github repo, didn't do any further configuration.

Not sure if there are some regex changes between 1.0.0-rc6 and 1.0.0-rc9?

Same issue as #14
In the radare2 source tree, from folder radare2/libr/core, coccigrep will only output results if I set -p 2 or higher. It seems to only work reliably with -p 3 or higher.
This outputs nothing:

coccigrep -t 'RDisasmState' -a 'show_reloff' *c

While this works:

coccigrep -t 'RDisasmState' -a 'show_reloff' *c -p 3

output:

disasm.c:654 (RDisasmState *ds):                ds->show_reloff = r_config_get_i (core->config, "asm.reloff");
disasm.c:2289 (RDisasmState *ds):                       if (ds->show_reloff) {

Likewise this this doesn't work:

coccigrep -t 'RDisasmState' -a 'show_reloff' *c -p 1

Hi, I'm issuing a simple command to look for usages of a given struct field:

coccigrep -t <type> -a <field> -o used src/*.[ch]

But I'm getting no output.
Strangely, if I run the same command on a few files, typing each of them manually, then I get results.

So, does coccigrep have a maximum number of files, beyond which it stops working?

Thanks for coccigrep! But, first time I see program which have colored output worse than non-colored. For example

linux/fs/ext4$ coccigrep  -t 'struct posix_acl' -a a_entries -c .
./acl.c: l.45 -0, l.45 +0, struct posix_acl *acl
                acl->a_entries[n].e_tag  = le16_to_cpu(entry->e_tag);
./acl.c: l.46 -0, l.46 +0, struct posix_acl *acl
                acl->a_entries[n].e_perm = le16_to_cpu(entry->e_perm);
...

Text struct is highlighted with bright green which distracts attention on every line from grep match to context column. Same search w/o colors is much easier to see:

./acl.c:45 (struct posix_acl *acl):             acl->a_entries[n].e_tag  = le16_to_cpu(entry->e_tag);
./acl.c:46 (struct posix_acl *acl):             acl->a_entries[n].e_perm = le16_to_cpu(entry->e_perm);
./acl.c:48 (struct posix_acl *acl):             switch (acl->a_entries[n].e_tag) {
./acl.c:61 (struct posix_acl *acl):                     acl->a_entries[n].e_uid =
./acl.c:69 (struct posix_acl *acl):                     acl->a_entries[n].e_gid =
./acl.c:105 (struct posix_acl *acl):            const struct posix_acl_entry *acl_e = &acl->a_entries[n];

But, it would benefit from colors. Can you make it by default to color just match text, like gnu grep do, and do not split lines into two? Also, why suddenly l.45 -0, l.45 +0 instead of just :45.