On Fri, 13 Nov 2009, Valdis.Kletnieks@xxxxxx wrote: > On Fri, 13 Nov 2009 22:26:20 +0100, Julia Lawall said: > > On Fri, 13 Nov 2009, Valdis.Kletnieks@xxxxxx wrote: > > > Julia, is there a way to use coccinelle to detect unsafe changes like that? Or > > > is expressing those semantics too difficult? > > > > Could you give a concrete example of something that would be a problem? > > If something like alias analysis is required, to know what strings a > > variable might be bound to, that might be difficult. Coccinelle works > > better when there is some concrete codeto match against. > > Here's a concrete example of how a previously audited strcmp() can go bad... > > struct foo { > char[16] a; /* old code allows 15 chars and 1 more for the \0 */ > int b; > int c; > } > > bzero(foo,sizeof(foo)); > > Now code can pretty safely mess with the first 15 bytes of foo->a and > we know we're OK if we call strcmp(foo->a,....) because that bzero() > nuked a[15] for us. It's safe to strncpy(foo->a,bar,15); and not worry > about the fact that if bar is 15 chars long, a trailing \0 won't be put in. > > Now somebody comes along and does: > > struct foo { > char *a; /* we need more than 15 chars for some oddball hardware */ > int b; > int c; > } > > bzero(foo,sizeof(foo)); > foo->a = kmalloc(32); /* whoops should have been kzmalloc */ > > Now suddenly, strncpy(foo->a,bar,31); *isn't* safe.... > > (Yes, I know there's plenty of blame to go around in this example - the failure > to use kzmalloc, the use of strncpy() without an explicit \0 being assigned > someplace, the use of strcmp() rather than strncmp()... But our tendency to > intentionally omit several steps of this to produce more efficient code means > it's easier to shoot ourselves in the foot...) Thanks for the example. Coccinelle only finds patterns of code in one version, while this would require considering two versions at once. Such a thing could be interesting though. julia -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html