NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/solaris/103

Text File | 1992-07-22 | 5.2 KB | 129 lines

Xref: sparky comp.unix.solaris:103 comp.sys.sun.apps:1447 comp.sys.sun.misc:3272 comp.sys.sun.admin:4863
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!agate!stanford.edu!rutgers!micro-heart-of-gold.mit.edu!xn.ll.mit.edu!ll.mit.edu!cynthia
From: [e-mail] (Cynthia Eldridge)
Newsgroups: comp.unix.solaris,comp.sys.sun.apps,ll.bboard,comp.sys.sun.misc,comp.sys.sun.admin
Subject: SUMMARY: Converting K&R to ANSI C
Message-ID: <[e-mail]>
Date: 22 Jul 92 14:04:13 GMT
Sender: [e-mail]
Organization: MIT Lincoln Laboratory, Lexington MA
Lines: 116
Originator: [e-mail] (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:
    [e-mail] (Michael Kade)
    [e-mail] (Guy Harris)
    [e-mail] (Keith Bierman fpgroup)
    [e-mail] (Aaron Dailey)
    [e-mail] (David G. Grubbs)
    david d `zoo' zuhn <[e-mail]>
    [e-mail]
    [e-mail] (Ronny Bergstrom)
    P.G.Griffiths <[e-mail]>
    Marc Evans - Contract Software Hacker <[e-mail]>
    [e-mail]
    [e-mail] (Juergen Nickelsen)
    [e-mail] (Dave Curry)
    [e-mail] (Graham Stead)
    [e-mail] (Andrew Arensburger - RMS)
    [e-mail] (Adam Bryant)
    pacdata![e-mail] (Jim Harkins)
    "Hilarie Orman" <[e-mail]>
    "Dan Franklin" <[e-mail]>
    [e-mail] ( Alan Stein )
    Peter Shipley <[e-mail]>
    [e-mail]
    [e-mail] (Fred Hoare)
    [e-mail] (Rand S. Huntzinger)
    [e-mail]
    "Dan Franklin" <[e-mail]>
    Mike Raffety <[e-mail]>
    [e-mail] (Georg Feil)
    [e-mail]
    [e-mail] (John Jarocki)
    [e-mail] (Greg A. Woods)

Cynthia Eldridge
--
Cynthia Eldridge
M.I.T. Lincoln Laboratory
[e-mail]