• Re: SUMMARY: Converting K&R to ANSI C

    From KP KP@21:1/5 to Cynthia Eldridge on Mon Aug 15 08:43:10 2022
    On Wednesday, July 22, 1992 at 7:04:13 AM UTC-7, Cynthia Eldridge wrote:
    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
    Thanks!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hume.spamfilter@bofh.ca@21:1/5 to KP KP on Wed Aug 24 01:31:30 2022
    KP KP <jungletrain@outlook.com> wrote:
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From KP KP@21:1/5 to hume.sp...@bofh.ca on Sat Sep 10 13:38:58 2022
    On Tuesday, August 23, 2022 at 6:31:35 PM UTC-7, hume.sp...@bofh.ca wrote:
    KP KP <jungl...@outlook.com> wrote:
    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?
    Lol, whoops. I guess it's a record.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)