Xref: utzoo comp.std.c:1227 comp.lang.c:19023 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!cline From: cline@sun.soe.clarkson.edu (Marshall Cline) Newsgroups: comp.std.c,comp.lang.c Subject: ANSI <--> K&R conversion utilities -- WANTED Message-ID: Date: 29 May 89 21:10:59 GMT Sender: news@sun.soe.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Organization: Clarkson University, Postdam NY Lines: 48 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(); (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); (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. (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. (6) The names of the header files could be changed/added/removed. (7) The variable argument schemes are different, so the code associated with and conversions could be made. (8) ???Other required features??? Anyone written anything like this/these? E-mail responses & I'll post a summary if there's enuf interest. Marshall -- ________________________________________________________________ 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