-ftree-check for review

[Nic Volanschi]

Hi,

This discussion has been very useful so far, so I would like to react once 
more on the last comments, and maybe ask your feedback about a new idea.

On Friday 04 May 2007 19:59, Tom Tromey wrote:
> Nic> 3) it doesn't warn you if you provide incorrect C
> Nic> patterns. That's probably what you meant, didn't you? That's also
> Nic> right, and I clearly recognize that this is the main disadvantage
> Nic> of unparsed patterns wrt parsed patterns.  However, what will
> Nic> happen? These patterns simply won't match anything, but you will
> Nic> not get any nasty error.
>
> Thanks for bringing this up.  This also does seem like a possible
> problem, since doesn't it mean that errors of various kinds can't be
> caught?  I'm thinking in particular that a change to GCC in this area
> might invalidate a user's script -- which could go unnoticed.  Or, a
> user could have an incorrect script but not ever see a diagnostic
> about it, leading him to believe that the check is working when in
> fact it is not.

That's true. So, as we rely on gimple, we depend on changing it. If we accept 
that, this is just a backwards compatibility issue. So for some changes in 
gimple (not all, in fact), the documentation should state that user-defined 
checks are not backwards compatible.

Is it acceptable? I don't know. Personally, I would say that user-defined 
scripts are not critical for correctly compiling a program. They're just some 
meta-files, the same way makefiles are. If a gcc option changes its syntax, 
you have to rewrite your makefile. That's a good analogy.

Now, here is the new idea. If we take from the patch just the simplified 
checks consisting in a single pattern, we get a "syntactic grep" feature, 
that is, a tool specialized for grepping C code. This way, we can search for 
calls to a given code pattern, e.g. opening files in read-write mode:

gcc --tree-check="%_ = fopen(%_, "rw")" *.c

The advantage over grep is of course that we don't care about indentation, 
comments, or line splitting. For example, we do match cases where the "mode" 
argument is on the next line, maybe even after three lines of comments.

In fact, the similarity to grep continues, because, like for grep, you don't 
have any guarantee that your pattern matches anything, and even less that is 
matches what you want. More than that, if you forget to escape your brackets, 
they'll match completely other patterns than you expected. But, in spite of 
that, everybody agrees that grep is useful, right? Why?? Because typically 
you prototype a few times your regexp, invoke grep a few times to see if it 
matches the intended pattern, and this costs you just a few minutes. That's 
the intended operating mode for --tree-check option, too.

So, maybe one way to go is just activate simple checks for the beginning, let 
people try them, and then see if we go further or not. What about that?

> I guess this goes back to having a solid definition of the condate
> language and a somewhat strict parser.

Unfortunately, this is not an option, or at least I don't know how to write a 
pattern parser. And, as no free or commercial compiler supports this, I'm 
afraid I'm not the only one who doesn't know.

Best regards,
Nic.