On Fri, Apr 25, 2008 at 12:15 AM, Alexey Zaytsev <alexey.zaytsev@xxxxxxxxx> wrote: [...] > > > - (maybe something else I've missed?) > > > > Most of the things in a sparse "struct symbol" would probably prove > > useful, I suspect. > > > May be. I'm still not really familiar with the sparse internals. I still don't buy the bytecode idea, but it seems that the macros are not actually lost after being pre-processed, which was my main concern against even thinking about dumping the sparse internal representation into the generated sparse object files. Still wandering in the dark. Will look closed when return. > > > > Eventually we will probably want something like the linearized > > bytecode. > > > > While I generally agree the we need to do something like > > sparse -> intermediate data -> checker > > the intermediate format is a bit unclear to me. It has to be verbose > enough to loose no essential information, and still be practical. > If by linearized bytecode you mean something like what we get > running sparse -ventry, this is clearly not going to work. As an > example, suppose you wish to check that local_irqsave() and > local_irqrestore() are balanced. This means, the checker actually > wants to look at the original source code, not even at the > pre-processed C code. > > So, suggestions on the intermediate format are welcome. > -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
