Automatic converters (PROTOIZE/UNPROTOIZE 1.05) now available

[Ron Guilmette]

PROTOIZE/UNPROTOIZE Version 1.05 is now available for anonymous
FTP from ics.uci.edu (128.195.1.1).  You can find this release
in the file ~ftp/pub/protoize-1.05.Z.  The size is 74123 bytes.

The file is also available for anonymous UUCP transfer from osu-cis.
The filename there is osu-cis!~/gnu/protoize/protoize-1.05.Z.

This version is compatible (only) with GCC version 1.36.

********** Read the new caveats below.  **********

Note that PROTOIZE/UNPROTOIZE is distributed only as a compressed
patch file.  You must uncompress the file, and then apply the patches
contained therein to a virgin copy of the GCC 1.36.

(GCC 1.36 is available from prep.ai.mit.edu in the /u/emacs directory
and via anonymous UUCP from osu-cis.)

For those of you who missed the previous announcements of prior
versions, the following summary is provided.

	Protoize is a tool which assists in the conversion of
	old style (K&R) C code to new style (ANSI) C code or to
	C++ code.  It does this by converting old (non-prototyped)
	function declarations and definitions to new (prototyped)
	declarations and definitions.  New function declarations
	will also be inserted into the converted code (as needed)
	in order to insure that all function calls are preceeded
	by explicit (prototyped) function declarations for the called
	functions.

	If you want to convert old K&R C code to C++, the conversion
	step that Protoize performs is absolutely essential.

	Conversion of old K&R C code to new ANSI C code (via Protoize)
	is useful in that it allows your ANSI C compiler to do more
	compile-time interface checking on function calls.

	Protoize is built to be used in conjunction with a modified version
	the the GNU C compiler (GCC).  The protoize package is distributed
	only as a patch file against the GCC (1.36) sources.   Man pages
	are included with the patches.

	For more detailed information about protoize, see the man page
	provided in the distribution patch file.

	This software has been generously donated to the Free Software
	Foundation by the Microelectronics and Computer Technology
	Corporation (MCC).


The changes in version 1.05 over version 1.04 are:

	-  Patching against a virgin GCC 1.36 should now proceed without
	   any failures.  I appologize for the 1.04 patching problems.
	   I accidently made the 1.04 patch file by diffing with a non-virgin
	   set of GCC 1.36 sources.  Oh, well!

	- The UNPROTOIZE program has been added.  This program has an
	  approximately inverse effect to that of protoize.  This means
	  that you can now write all of your programs in ANSI-C and only
	  convert them to old K&R style C (automatically) when (and if)
          you need to (because you have some machine which *doesn't* have
	  an ANSI-C compiler).  Thus, people now have one less excuse not
	  to change over to ANSI-C.

	- An important bug which caused excessive memory allocation has
	  been fixed.

	- Several other fixes for minor bugs have been implemented.

Outstanding problems:

	Five problems in the current (1.05) release have been pointed out
	to me:

	(1)  It appears that protoize will convert this:

		typedef char *caddr_t;

		myfunc (arg)
		    char *arg;
		{
		}

	to this:

		myfunc (caddr_t arg)
		{
		}

	which is probably not what you wanted.  Is seems that protoize is a
	bit too eager in seeking out typedef names (actually this is happening
	inside of GCC).  This *should* be fixed in the next release.

	(2)  In the Makefile,  the protoize and unprotoize targets should
	also depend on $(INCLUDES).  This will be fixed in the next release.

	(3)  The std.c file does not contain *all* the prototypes for system
	routines that you might ever want and/or need.  (Specifically, one
	person noticed that prototypes for puts() and sscanf() should be
	added.  These two will be added in the next release.  Should I add
	any others?

	(4)  Protoize and unprotoize should *never* try to convert your
	"system" include files (unless forced to somehow).  The way things
	stand now (1.05) if you run protoize/unprotoize as user root, you
	may accidently & unintentionally affect your system include files.
	This will be fixed in the next release.

	(5)  The final problem is with unprotoize.  Two people pointed out
	that a naive unprotoization of existing ANSI code will *not*
	necessarily yield code that is still "correct".  This is because
	unprotoization causes you to lose the implicit casts which are
	automatically applied (by your ANSI compiler) to actual arguments
	in calls to prototyped functions.  The easiest solution to this
	(potential) problem with unprotoize is to add a -Wimplicit-cast
	option to GCC and let people use it to (manually) eliminate all such
	implicit casts by inserting *explicit* casts into their code prior
	to actual unprotoization.  This idea has two things going for it.
	First, it should be trivial for me to implement it (and all other
	possible solutions for this problem are drastically harder).  Second,
	I never much liked *implicit* casts anyway.  I believe that they make
	code harder to read/interpret/maintain.

	In the next release, I will probably implement the -Wimplicit-cast
	solution and let somebody else have a whack at implementing a better
	solution.

Did I miss anything?

Oh, yes.  Because C++ now wants to see extern "C" {} wrapped around most
includes of system include files, I may provide a mechanism for generating
these new "language brackets" in the next release of protoize.  If I do,
the brackets themselves will probably be conditionally included based on
the definition status of the preprocessor symbol _cplusplus.

Regarding complaints:

	Please don't gripe if protoize/unprotoize doesn't wax your car,
	take out the garbage, or feed your cat.  It was not designed to
	do these things.  Neither was it designed as a tool for TOTALLY
	AUTOMATING the conversion process.  Rather, the protoize & unprotoize
	programs were designed only as *aids* in the conversion process.
	They do the stuff that is *easy* to automate, leaving a human to do
	the tricky parts.  If you feel that some other aspects of conversion
	can also be easily automated, please feel free to have a whack at
	it yourself.  I'll be glad to share ideas and source code with you
	but my time to implement nifty new features myself is limited.
	You see there is this little matter of the PhD that I'm also supposed
	to be working on from time to time! :-)

	If you insist on FULLY AUTOMATIC conversion, then just send me
	$18 bizillion (cash only) and I'll have the program all ready for
	you first thing next century. :-)

**** I need some feedback!!! *****  Rms is considering including protoize/
unprotoize in future releases of GCC, but he will not bother if nobody thinks
that these programs are useful.  Can you blame him?

	****************** PLEASE PLEASE PLEASE *********************

Send your comments (either positive or negative) regarding protoize/unprotoize
to:

	rms at wheaties.ai.mit.edu

Also please CC: me at:

	rfg at ics.uci.edu

My thanks to those people who already sent in their comments.  It appears that
there really are some people who find these tools useful!

// rfg (rfg at ics.uci.edu)