andrew@frip.WV.TEK.COM (Andrew Klossner) (08/02/89)
I compile G++ with a GCC that does type checking of arguments to strcpy.
It complained about this line from procedure stash_inline_prefix in
file cplus-method.c in G++ 1.35.0:
OB_PUTS (DECL_NAME (result));
I changed it to:
OB_PUTS (IDENTIFIER_POINTER (DECL_NAME (result)));
and the syntax warning message went away.
Was this right?
-=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (08/02/89)
Me thinks someone should with copious amounts of spare time should run all of gcc through Rons ``protoize'' package and distribute the prototypes. Ideally, this would be a beta-gcc user so us other beta-users would benefit from this as well. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (08/03/89)
That was right. Don't know why I didn't see that... Michael
rfg@dg-rtp.dg.com (Ron Guilmette) (08/22/89)
In article <GRUNWALD.89Aug1171636@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: > >Me thinks someone should with copious amounts of spare time should >run all of gcc through Rons ``protoize'' package and distribute >the prototypes. Thanks for the vote of confidence Dirk. [ Note that if GCC were altered slightly, you could run "protoize" yourself, and thus generate the prototypes yourself. Why waste net bandwidth sending out stuff that could be generated locally directly from the sources (automagically)? ] Actually, the primary thing that motivated me to build the protoizer was the idea of getting G++ to the point where it could be used to bootstrap itself (just like GCC does). I felt that G++ had some reliability problems which could be diminished (somewhat) by making a bootstrap part of the standard build process (as for GCC). After all, it is clear that one good way to test a compiler (although not the only one) is to run some relatively sizable chunk of code through it and then check that the resulting executable seems to perform as expected. If we take this as a given, there are only two questions remaining. First, "Where do we get our 'sizable' chunk of XYZ language code to test our XYZ compiler with?", and "How can we easily do a 'spot' check on the resulting executable?" GCC has a simple answer for both questions. Obviously, since you are building GCC, you (probably) have all of the GCC source code itself right there with you. (Fortunately, it is all written in the same language that the compiler itself compiles.) Thus, you don't have to hunt around on the net for some *other* batch of sources. Also, it is simple to spot check any executable produced from the GCC sources simply by trying to use the given executable to compile some code (the more the better). Anyway, one day I said to myself, "If C is a proper subset of C++, then why can't G++ be bootstrapped just as GCC is, thus providing at least one sizable test case?" The answer is complicated, but it mostly boils down to the fact that C is *not* a proper subset of C++. The big issue (of course) is function prototypes. I wrote a tool to insert the prototypes automatically, but this simply brought to light a number of other more minor compatability issues. (See my recent posting to comp.lang.c++). Rather than starting out with the G++ sources, I decided to start my quest with the GCC sources and then "move up". I protoized all of the GCC sources, and then made minor changes (as required) to get the result to recompile. Many/most of the changes simply brought the GCC sources up to full ANSI-C (i.e. converting to <stdarg.h> conventions rather than the obsolete <varargs.h> conventions). Of course, I wrapped all of my ANSI-specific changes in #ifdef __STDC__. I sent all of my resulting patches back to rms, and (much to my aggravation) he declined to incorporated *most* of my changes back into the GCC sources. I pointed out that his failure to do so meant that the GCC sources would remain (at least somewhat) non-ANSI, and his response was that he didn't care if the GCC sources were non-ANSI (and non-G++ compatible). He basically told me that his sense of estetics was more important to him that what any ($%^#*&) compiler thought. In all fairness, I do have to say that rms *did* incorporate all of my patches which fixed obvious (function-calling) bugs and all other trivial patches which did not offend him. Anyway, protoizing GCC did uncover some bugs, and this same process would (I believe) uncover even *MORE* bugs in G++. Thus, for the sake of reliability (which, I believe everyone will agree, we need more of) I had hoped (and still do hope) that "protoization" will become a standard part of a standard GCC/G++ build. The process is FAST and it *does* uncover bugs (automagically). I hope to have time (soon?) to make the process even faster by completing the implementation of the (undocumented) -fsyntax-only option to GCC (which I already have 95% working). In order to further encourage FSF's use of the protoizer tool, it has (generously) been donated to FSF by my former employer (MCC). I stand ready to continue my work with the protoizer on the compiler sources (at no charge to FSF) to enhance the reliability of GCC (and let's not forget G++) for the common good of the Free Software community. All I ask is that the job not be made more difficult that it rightly has to be (i.e. that "minimally necessary" patches be incorporated into GCC/G++ sources to make them all ANSI-C/C++ compatible, so that I will not have to "re-patch" each new release in order to continue). // Ron Guilmette rfg@dg-rtp.dg.com