Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!sun.soe.clarkson.edu!cline From: cline@sun.soe.clarkson.edu (Marshall Cline) Newsgroups: comp.std.c Subject: Re: ANSI <--> K&R conversion utilities - COMMING SOON Message-ID: Date: 2 Jun 89 21:47:31 GMT References: <229@pink.ACA.MCC.COM> <10311@socslgw.csl.sony.JUNET> Sender: news@sun.soe.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Followup-To: comp.std.c Organization: Clarkson University, Postdam NY Lines: 44 In-reply-to: diamond@diamond.csl.sony.junet's message of 31 May 89 05:34:12 GMT In article <10311@socslgw.csl.sony.JUNET> diamond@diamond.csl.sony.junet (Norman Diamond) writes: >In article 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