rfg@pink.ACA.MCC.COM (Ron Guilmette) (05/31/89)
In article <CLINE.89May29171059@sun.soe.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes: >In all likelihood we'll all be living in the transition from K&R to ANSI-C >for a long while. Like most of us (probably), I've written a macro package >that converts prototypes for ANSI/K&R compatibility. However this is only >a partial fix. What I'd really like is a real program that filters a K&R >module and spits out an ANSI module (and another filter for the vise versa >operation). I can see a number of things this/these filter[s] would need >to do, including: > >(1) Convert between K&R & ANSI prototypes in function _DEFINITIONS_. Ex: > ANSI: double myfunct(int i, int j) {... > K&R: double myfunct(i, j) {int i, j; ... > >(2) Convert between K&R & ANSI prototypes in function _DECLARATIONS_. Ex: > ANSI: double myfunct(int i, int j); > K&R: double myfunct(); I have a program which does (1) and (2) above. It is written in C (fairly portable) and it seems to be quite fast (not that that matters much). The important thing is that it seems to do a good job for perhaps > 95% of all declarations and definitions (based on a large test case, i.e. the GNU C compiler). The only cases where it will mess up is where there are MACRO calls in the vicinity of the thing being protoized, or where some style (new or old) of varargs stuff going on for a particular function. Both cases are rare in practice. If you embed comments in your function headers, this can also cause a failure, although many such cases are handled correctly. One nice aspect to my tool is that it converts a whole *system* of code. That is to say it can use information gleaned from a K&R style function definition in one file to protoize a function declaration for the same function in some different file (usually an include file). Protoization is useful for conversion to either ANSI C or to C++. My protoizer works in two steps. First, prototype information must be collected. A fairly brute-force approach is used for this step. I use a modified version of the GNU C compiler to collect the prototype information. Once this information has been collected for all relevant source files, the "protoize" tool gobbles up this information and automatically edits prototypes into all relevant source files (except system include files, or other files that the user does not have write access to). The protoizer has been tested on the GCC compiler itself, which is (I believe) somewhere in the neighborhood of 150,000 lines of code. It handled all proto- typing correctly, and only got a little confused by the (occasional) varargs functions. Depending on the speed with which a legal handover of this code to the Free Software Foundation is executed, I hope to see FSF distributing this code to all interested users fairly soon. >(3) In the case of "int" functions, many ANSI prototypes would have to be > added to the code before they are called (starting to get messy). Ex: > if "myfunct(x, y)" is called in the K&R code but isn't declared > previously, it could be assumed to return an "int", and its parameter > types could presumably be figured out, resulting in an ANSI prototype: > int myfunct(foo_t param1, bar_t param2); You can get GCC to warn you about implicit function declarations. I suggest that you do this, and then add in explicit (K&R) declarations where needed. Later, you can use my protoizer to get them automatically ANSI-fied. >(4) When converting from ANSI to K&R, the "automatic cast" facilities > provided by the prototypes would have to be changed to "explicit casts". > Ex: If "myfunct()" accepts a "long", and "i" is an "int", then the > ANSI code "myfunct(i)" would have to be translated to "myfunct((long)i)" > for the K&R compilers. Who wants to go backwards? >(5) In the reverse of (4), explicit casts to parameter types might be > removable when K&R code is translated to ANSI. See example just above. Leave them in. They do no harm. >(6) The names of the <standard> header files could be changed/added/removed. Wait until somebody has a <standard> set of header files before you do this. >(7) The variable argument schemes are different, so the code associated with > <varargs.h> and <stdarg.h> conversions could be made. Yep. That's a problem. It will probably have to be solved "by hand". -- // Ron Guilmette - MCC - Experimental Systems Kit Project // 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740 // ARPA: rfg@mcc.com // UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
diamond@diamond.csl.sony.junet (Norman Diamond) (05/31/89)
In article <CLINE.89May29171059@sun.soe.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes: > >(4) When converting from ANSI to K&R, the "automatic cast" facilities > > provided by the prototypes would have to be changed to "explicit casts". > > Ex: If "myfunct()" accepts a "long", and "i" is an "int", then the > > ANSI code "myfunct(i)" would have to be translated to "myfunct((long)i)" > > for the K&R compilers. In article <229@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: >Who wants to go backwards? Anyone who has to use a K&R compiler, e.g. PCC. Technically this doesn't answer the question; this answers "Who HAS to go backwards?" Anyway, Mr. Cline is right; the perverse transform is also useful. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
djones@megatest.UUCP (Dave Jones) (06/02/89)
> In article <229@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: > >>Who wants to go backwards? > It's the implied concept of backwards and forwards is backwards. Assuming that you like ANSII-C better than C, one wants an (ANSII-C)-to-C compiler so that one can make the "forward" step to writing in ANSII-C rather than in C. There are lots of C compilers around. If we had just one ANSII-C to C compiler, we would then have lots of ANSII-C-to-machine-code compilers. I could use an ANSII-C-to-C compiler. It's the same reason that cfront compiles C++ into C.
cline@sun.soe.clarkson.edu (Marshall Cline) (06/03/89)
In article <10311@socslgw.csl.sony.JUNET> diamond@diamond.csl.sony.junet (Norman Diamond) writes: >In article <CLINE.89May29171059@sun.soe.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes: >>>(4) When converting from ANSI to K&R, the "automatic cast" facilities >>> provided by the prototypes would have to be changed to "explicit casts". >>> Ex: If "myfunct()" accepts a "long", and "i" is an "int", then the >>> ANSI code "myfunct(i)" would have to be translated to "myfunct((long)i)" >>> for the K&R compilers. >In article <229@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: >>Who wants to go backwards? >Anyone who has to use a K&R compiler, e.g. PCC. Technically this >doesn't answer the question; this answers "Who HAS to go backwards?" >Anyway, Mr. Cline is right; the perverse transform is also useful. Actually, I think going "backwards" will be much more important in a few years than it is now (think about it -- that sounds "backwards"). The reason is: Right now we have a higher percentage of K&R code, so most of our conversion will be K&R --> ANSI. In a few years (months? days?), people will be developing good, decent, useful, necessary, exciting things in ANSI-C. When this happens, those of us who still use K&R compilers (which will probably be a lot of us) will have to bring the new code "backwards" to the K&R style. In short, if we don't have an _AUTOMATED_TOOL_ to _EFFECTIVELY_ and _RELIABLY_ convert ANSI to K&R, "for portability's sake" we'll be tempted to write _everything_ in K&R C, short-circuiting the advantages of the Standard. Marshall PS: I still haven't gotten many e-mail responses. Anyone have any great ideas, please send them to me -- I'll post results. -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
cline@sun.soe.clarkson.edu (Marshall Cline) (06/03/89)
In article <5472@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >> In article <229@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: >>>Who wants to go backwards? >It's the implied concept of backwards and forwards is backwards. >Assuming that you like ANSII-C better than C, one wants an (ANSII-C)-to-C >compiler so that one can make the "forward" step to writing in ANSII-C >rather than in C. >There are lots of C compilers around. If we had just one ANSII-C to C >compiler, we would then have lots of ANSII-C-to-machine-code compilers. >I could use an ANSII-C-to-C compiler. >It's the same reason that cfront compiles C++ into C. Actually, I think going "backwards" will be much more important in a few years than it is now (think about it -- that sounds "backwards"). The reason is: Right now we have a higher percentage of K&R code, so most of our conversion will be K&R --> ANSI. In a few years (months? days?), people will be developing good, decent, useful, necessary, exciting things in ANSI-C. When this happens, those of us who still use K&R compilers (which will probably be a lot of us) will have to bring the new code "backwards" to the K&R style. In short, if we don't have an _AUTOMATED_TOOL_ to _EFFECTIVELY_ and _RELIABLY_ convert ANSI to K&R, "for portability's sake" we'll be tempted to write _everything_ in K&R C, short-circuiting the advantages of the Standard. Marshall PS: I still haven't gotten many e-mail responses. Anyone have any great ideas, please send them to me -- I'll post results. -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591