rfg@ics.uci.edu (Ron Guilmette) (10/23/89)
PROTOIZE/UNPROTOIZE Version 1.05 may soon be available for anonymous
FTP from ics.uci.edu (128.195.1.1).
This version is compatible (only) with GCC version 1.36.
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.
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:
- 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.
I would make this software available immediately, but I have one small
problem.
I have already sent many copies of this software to many people via E-mail,
and I'm sure that many others have gotten copies via FTP, but people don't
seem to be willing to take the time to drop me a short note (via E-mail)
telling me what they think of protoize.
**** 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@wheaties.ai.mit.edu
Also please CC: me at:
rfg@ics.uci.edu
I will make version 1.05 available as soon as I have received 3 comment letters.
*** CONVERSION SERVICE: If you have a large system that you would like to
have converted from old K&R C to ANSI-C or to C++ or an ANSI C program that
you want converted to old K&R C, and if you do not want to do this work
yourself, please contact me via E-mail. I am willing to perform such
conversions for a modest fee.
// rfg (rfg@ics.uci.edu)dhesi@sunseeker.UUCP (Rahul Dhesi) (10/26/89)
In article <1989Oct22.113105.29034@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes: > 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. What I really need is a tool that takes either int xyz(char *c, FILE *f); or int xyz(); and produces: #ifdef ANSIPROTO int xyz(char *c, FILE *f); #else int xyz(); #endif Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi Use above addresses--email sent here via Sun.com will probably bounce.
rfg@ics.uci.edu (Ron Guilmette) (10/28/89)
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@wheaties.ai.mit.edu
Also please CC: me at:
rfg@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@ics.uci.edu)rfg@ics.uci.edu (Ron Guilmette) (10/28/89)
In article <1004@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In article <1989Oct22.113105.29034@paris.ics.uci.edu> rfg@ics.uci.edu >(Ron Guilmette) writes: >> 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. > >What I really need is a tool that takes either > > int xyz(char *c, FILE *f); > >or > > int xyz(); > >and produces: > > #ifdef ANSIPROTO > int xyz(char *c, FILE *f); > #else > int xyz(); > #endif Many people have asked for this effect. Please note that you can create such "composite" files yourself if you have a version of "diff" which supports the -D option. The SunOS "diff" does. I hope that somebody will implement this in GNU diff soon. // rfg
7103_300@uwovax.uwo.ca (10/28/89)
In article <1004@cirrusl.UUCP>, dhesi@sunseeker.UUCP (Rahul Dhesi) writes: > What I really need is a tool that takes either > > int xyz(char *c, FILE *f); > > or > > int xyz(); > > and produces: > > #ifdef ANSIPROTO > int xyz(char *c, FILE *f); > #else > int xyz(); > #endif I posted such a tool (mkproto) to comp.sources.misc a while back; it produces int xyz P((char *c, FILE *f)) along with an appropriate definition for P. Mkproto has some limitations, but it works well on most "common" code (e.g. I used it to produce prototypes for Omega, with no problems).
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/30/89)
In article <1989Oct27.190150.22043@paris.ics.uci.edu>, rfg@ics.uci.edu (Ron Guilmette) writes: | >and produces: | > | > #ifdef ANSIPROTO | > int xyz(char *c, FILE *f); | > #else | > int xyz(); | > #endif I might suggest that this could make for large and possibly hard to read code, and that it have the declarations in two places, with the possibility that future editing will add/delete/change only one. I offer the following suggestion which some people may find useful. Define a macro: #ifdef ANSIPROTO #define PARAM(x) x else /* old style */ #define PARAM(x) () #endif /* meaning of PARAM */ Then you can say (note two levels of parens): extern lsf PARAM((int, int, int*)); This results in only one line for the prototype, and is still pretty readable. You can include names or just types as you please. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon