SUMMARY: Converting K&R to ANSI C
Cynthia Eldridge
I received many helpful replies in response to my plea for
recommendations/comments/advice on the best way to convert
a very large volume of Kernighan and Ritchie C (K&R) to ANSI-C
(ACC). I asked several questions hoping to get an idea on the
best way to convert our software. In particular, we are trying to
decide whether we should convert our software all at once to ACC,
perhaps locking it for weeks, or whether we should convert our
software gradually.
Basically, the 30 or so responses can be summed up as follows, with
the total number of folks who mentioned the response in ():
1. Don't worry; the Sun compiler has special flags that will support
a gradual transition. (11) These flags are:
-Xt supports K&R and ACC; uses K&R semantics
-Xa supports K&R and ACC; uses ACC semantics
-Xc strictly ACC
2. Don't worry; gcc supports K&R and/or ACC. (16)
3. Require new projects and rewrites to be ACC; use the Sun compiler's
-Xt flag for old projects. Clean up old projects gradually. (4)
4. Use lint. (4)
5. Protoize very useful; start with it. (4)
6. Cproto useful, but doesn't handle typedefs. (4) One person said it was
"a bit of a pain" to use.
7. Convert all at once, using utility (like protoize or cproto). (5)
8. One person sent document on managerial aspect, which pointed out that
conversion can be tricky and that having good programmers is important.
9. Convert gradually using macros. (7) For example, the Sun compiler has a
predefined macro, __STDC__, which has value 0 for -Xt and -Xa, and
has value 1 for -Xc.
10. There are other compilers, such as MIPSco, that support K&R and ACC. (1)
11. The PipeLine Tool, "svmt", provided by Sun on the Solaris 2.0 Migration
CD, is useful. (1)
12. Be careful: in ACC, some K&R preprocessor identifiers may no longer be
valid (e.g., "." should not be in a preprocessor). (1)
Also, note that ACC and K&R treat unsigned types differently, have
different variable argument list handling, treat "trigrams" (a 3 to 1
character conversion) differently, etc. (1)
Beware of K&R code that addresses (char *) 0 or that frees an
unallocated pointer; it won't work in ACC. (1)
13. One person wrote a package called "cextract" to generate header files
containing full prototypes of functions. The headers include a macro
to allow them to be compiled in ACC or in K&R.
14. Don't use automatic converters because they may introduce typos. (1)
15. Don't change anything else when converting the code to ACC to
eliminate potentially introduced bugs. (1)
16. Gnu ghostscript comes with a program ansi2knr.c. (1)
17. Centerline (Saber) from CodeCenter is a possibility. (1)
18. QA*C is good for writing maintainable code of high quality, but not
recommended for merely converting from K&R to ACC. (1)
19. I presented a scheme to typedef library functions to ensure that
if the library was compiled in K&R and if the application calling
the library function was compiled in ACC (or vice-versa), then the
function would not be promoted to something unexpected. (For example,
all functions returning float would be typedef'd to return double
because K&R promotes floats to doubles but ACC does not.) Two people
said this scheme sounded OK. One person said that it sounded too
complicated and thus prone to error.
Much thanks to:
Mike...@West.Sun.COM (Michael Kade)
g...@auspex.com (Guy Harris)
Keith....@Eng.Sun.COM (Keith Bierman fpgroup)
aar...@stortek.com (Aaron Dailey)
d...@ksr.com (David G. Grubbs)
david d `zoo' zuhn <z...@cygnus.com>
n...@cl.cam.ac.uk
Ronny.B...@eua.ericsson.se (Ronny Bergstrom)
P.G.Griffiths <P.G.Gr...@uk.ac.daresbury>
Marc Evans - Contract Software Hacker <ev...@zk3.dec.com>
r...@ll.mit.edu
nic...@desaster.cs.tu-berlin.de (Juergen Nickelsen)
da...@ecn.purdue.edu (Dave Curry)
gst...@ux5.lbl.gov (Graham Stead)
are...@kong.gsfc.nasa.gov (Andrew Arensburger - RMS)
a...@albert.bu.edu (Adam Bryant)
pacdata!ji...@UCSD.EDU (Jim Harkins)
"Hilarie Orman" <h...@cs.arizona.edu>
"Dan Franklin" <d...@diamond.bbn.com>
al...@ll.mit.edu ( Alan Stein )
Peter Shipley <shi...@tfs.COM>
Perry_Hutchi...@xerox.com
fr...@dip1.ee.uct.ac.za (Fred Hoare)
ra...@ncbi.nlm.nih.gov (Rand S. Huntzinger)
Steve_...@gec-epl.co.uk
"Dan Franklin" <d...@diamond.bbn.com>
Mike Raffety <mi...@sbcoc.com>
ge...@sgl.ists.ca (Georg Feil)
s...@svb.guug.de
jar...@dvorak.amd.com (John Jarocki)
wo...@robohack.ll.mit.edu (Greg A. Woods)
Cynthia Eldridge
--
Cynthia Eldridge
M.I.T. Lincoln Laboratory
cyn...@ll.mit.edu
hume.sp...@bofh.ca
> On Wednesday, July 22, 1992 at 7:04:13 AM UTC-7, Cynthia Eldridge wrote:
> Thanks!
This is a new record, I think.
You're responding to a post over THIRTY YEARS OLD.
Do you really think the person you're responding do is checking up for
replies?
