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! 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] > 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 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...). > 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! > 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? 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). > 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. 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. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
