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!

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?

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.