On 29/04/2011 13:16, Basile Starynkevitch wrote:
On Fri, 29 Apr 2011 12:30:45 +0200
David Brown<da...@westcontrol.com> wrote:
There is a lot of interesting and useful work that could be done here.
Melt is a nice idea, but the big barrier (for me, anyway) is the
language - it's Lisp, which is very different to other languages that
I've used.
Pierre Vittet knows MELT quite well and has already successfully used
it (and he did found some bugs in MELT that I was happy to correct). He
is one of the most active posters on the
gcc-melt-fre...@googlegroups.com list. We (Pierre& me Basile) met
regularily (with Alexandre Lissy). Pierre is perhaps one of the best
(and few) MELT users. So MELT is definitely no more an obstacle for him!
I wasn't thinking of MELT's language as an obstacle for Pierre - but for
us mere mortal C programmers. That's why this is such a good idea for a
project if it lets people like me get extra checks without having to
learn MELT and Lisp.
And regarding the Lispy syntax, I do have a infix syntax in the works.
However, contrarily to many others, and conforming to Pierre's
experience, the hard part is not learning MELT syntax (which is looking
similar to e.g. Elisp or Scheme or Common Lisp code, so learning MELT
is fast if you did try Elisp or Scheme before), the hard part is
learning GCC internals. Pierre struggled much more understanding where
to insert his pass and what precise kind of Gimple he wants to detect
than with the MELT syntax. So my feeling is even more than before that
MELT lispy syntax is not important: providing an infix syntax to MELT
(which in my eyes would be parsed into exactly the same abstract MELT
trees as the current lisped syntax) is a significant amount of work,
and I am not sure at all it will buy new users to MELT. Hence a
question to David Brown: will he use MELT if it had an infix syntax
(but all the rest of MELT being the same)? [I am not sure, and this is
why making an infix syntax is not my priority]
Perhaps I wasn't clear here (or perhaps I misunderstood Pierre's first
post). I am not suggesting changing the language for MELT - I assume it
uses Lisp because the developers thought that's a good language for such
pattern-matching applications. While my Lisp knowledge is very
rudimentary, I can easily see it's a better choice than, for example, C
- I am a big fan of choosing appropriate languages for the task in hand,
rather than trying to do everything with the one language. Of course, I
am a bigger fan of people using languages I already know - I am sure
Python is the ideal language for MELT :-)
As far as I understand Pierre's project, it will let users like me get
configurable warnings using a simple syntax on the gcc command line -
and that's great. The language used by Pierre is then an implementation
detail that doesn't affect me as a user (unless I want to fiddle with
the source myself) - it doesn't matter whether I like Lisp or not,
because I won't see the Lisp code.
As to whether I would be more likely to use MELT if it had another
language - probably I would be a little more likely to try it. But as
you say, the language is only one part of the issue - understanding how
gcc works and how to fit in with it is a far bigger challenge. What
would make me much more likely to try it is lots of examples, or
library-style code so that I could have something useful (not "hello,
world!") to start with, that I could modify easily. At that point, the
choice of language would be a much smaller matter. Of course, it's quite
possible that such easy-to-use examples are not practically possible -
gcc is a very complicated piece of software.
For the longer term, it would be good if there were a way to use this
with windows (and without installing all of cygwin). I know these things
are /much/ easier on Linux, but gcc is getting increasingly popular on
windows. I work as an embedded programmer, and steadily more embedded
systems are programmed using gcc - often on windows hosts.
Most gcc users are C or C++ programmers - while they might
like the idea of having customised warnings or checks, it would take
them a great deal of work to learn enough Lisp to get something useful
from melt.
No, the idea is that the users of Pierre's work will just invoke gcc
with appropriate (and indeed lenghty) option, perhaps something as
simple as gcc -fplugin=melt -fplugin-arg-melt-mode=give-posix-warnings
-c -O2 foobar.c so that means essentially adding
CFLAGS += -fplugin=melt -fplugin-arg-melt-mode=give-posix-warnings
in a Makefile. If Pierre coded a specific plugin directly in C (a
seperate plugin for each family of warnings), that would be much more
work for him (since he does know MELT!) and indeed the user of such a
plugin would have to pass
CFLAGS += -fplugin=some-plugin-to-give-posix-warnings
Yes, I understand that now (I've read more since my first post). That
sounds excellent.
I (Basile) don't think it is such a big issue for the users of Pierre's
work. And Pierre (and of course me Basile) prefer to code in MELT
instead of C (because there is no pattern matching in C, while there is
a quite powerful pattern matching in MELT to match Gimple or Tree-s...).
I agree entirely - a few extra options inside a makefile makes no
difference to the user, and is certainly worth it for the MELT developers.
So if you manage to make something that C and C++
programmers can easily make use of, then that would be great.
Again, the goal of Pierre's work is to give a set of extra contextual
warnings to users. Users of Pierre code don't need to understand the
MELT lispy syntax (and they don't need neither to understand what is a
Gimple or a Tree). But Pierre need to know all (MELT, what is a
Gimple... and understanding Gimple is much harder than understanding
MELT syntax).
Another problem with Melt is that it is inconvenient to install and use,
Did you try the latest MELT plugin from http://gcc-melt.org/ (the 0.7
was released but I did not announce it yet, because I want to write a
small tutorial docuemntation) ? It is a plugin for GCC 4.6 (I put it
there a few days ago), and can be installed (by running a script given
inside the MELT plugin source tar ball) as a melt.so plugin. I am
surprised by the "inconvenient to use" phrase. MELT is just a [meta-]
plugin, it is as easy to use as any other plugin.
and slow to run - if you make a layer on top of that, it will be worse.
MELT is not that slow (what is slow is indeed the translation of C code
generated by MELT from a *.melt file; the translation from *.melt to
*.c is quite fast.). For the kind of checks that Pierre wish to
implement, MELT seems definitely the right tool, it was designed for
such use. For the simple pass that Pierre already coded in MELT, using
it on the entire readline6 source code to find untested calls to fopen
did not slow much the compilation time (but I have no figures for that
claim, just an impression). Besides, I want a lot to improve these
issues!
I'm going to have to beg forgiveness here - my comments were based on a
misunderstanding of how MELT works, as well as being based on reading
about MELT when it was first started (when gcc plugins were also a new
concept) rather than the current versions.
This is not necessary a major issue, but it will typically mean that
the extra checking will be done as a separate "make target" rather than
as a standard compile option (such as is done with normal gcc warnings).
I dont understand that point. Once Pierre developped his GCC extensions
in MELT, using them is nearly as simple as using any other plugin,
except that one have to pass an extra -fplugin-melt-arg-mode=XXXX
argument. Is that such a big deal?
Again, that was my misunderstanding. I was under the impression that the
Lisp code was interpreted as part of the user compile process, which
would be slow for large programs - especially if you have a lot of checks.
But of course, adding extra checks is costly, and probably MELT is 2 or
4 times slower than native hand written C. So what? The passes written
by Pierre won't run for long (since they are essentially shallow
verifications and don't transform Gimple, just analyze it).
It is indeed worth that cost - computer time is a lot cheaper than
developer time. My mistake was that I thought the factor would be much
higher than that, because I didn't realise the MELT code is translated
to C and compiled for the plugin.
Of course, if Melt makes it easier to do this development then it's a
good choice - speed issues can be looked at later, once you know the
idea is good.
Have you also considered looking at other types of static checking? The
ideas you have so far are definitely interesting, but there is scope for
much more in the same vein. Checks aimed at spotting potential buffer
overflows or security issues are always popular. Another idea is to
enforce style or coding standard checks. Of course, complete
implementations of such checks would keep you busy for a lot longer than
the summer - but it might be interesting to think about.
Yes, these are the checking Pierre have in mind. Buffer overflow (or
security issues) is more a semantic issue (it requires some abstract
interpretation techniques with real lattices, and Pierre won't have
time for that). BTW, if you are interested in these issues, you could
look at http://frama-c.com (a free C code analyzer coded in Ocaml by
colleagues). But Frama-C requires users to specific formally the
intended behavior of their code (and such a formalization is a hard
work). Frama-C is targetted towards very safety critical code (e.g.
Airbus embedded software in planes, or embedded software in nuclear
power plants), for which high development costs are accepted.
If such checking software were easy to make and use, I'm sure we'd
already be using it! And I'm also aware that defining the rules to check
can be as much or more effort that writing the rule-checker.
There are a few other C code analysers around - pc-lint is a non-free
one, and there is the venerable splint, which has pretty much stagnated.
The other interesting open-source checker that I know of is
<http://clang-analyzer.llvm.org/>.
And I do know that Pierre will find other bugs in MELT (he already did)
and I am delighted of that -hoping to improve MELT this way, by having
it used.
Regards.
I wish you both luck with the project and the plugin. And thank you for
clearing up my misunderstandings!
Regards,
David
