Converting ANSI-C to non-ANSI-C, Please help.

[Ron Guilmette]

In article <712 at modulex.dk> morten at modulex.dk (Morten Hastrup) writes:
+Does anyone out there have/know of any tool(converter) capable
+of converting ANSI-C to non-ANSI. Ex.:

Yes.  I have built a pair of tools called protoize & unprotoize.  A new
version of these is now being pre-tested.  If you have a burning desire
to get your hands on the latest versions of these tools, and if you
know how to build & install the GNU C compiler (GCC) and if you have
access to the Internet (so that you can do anonymous FTP's) please
contact me by E-mail, tell me what you plan to use these tools for,
and I may make you a pre-tester for the new version.

+	return_type function(type1 arg1)
+	{
+	   .... /* something is going on */
+	}
+
+  is converted into:
+
+	#ifdef __STDC__ /* or something other than __STDC__ */
+	return_type function(type1 arg1)
+	#else
+	return_type function(arg1)
+	type1 arg1;
+	#endif
+	{
+	   .... /* something is going on */
+	}
+
+My problem is that our sun doesn't have any ANSI compiler.

There is a simple solution to that problem.  Get GNU!  Its free.

By the way, your example makes me want to comment (... well... vomit
actually).

One thing that I have tried to stress to all users of protoize & unprotoize
is that putting all of those #ifdef __STDC__ directives into your code is
dumb, stupid, ugly, and unnecessary, and that it actually *degrades* (by
a significant amount) the "quality" of your code.

It would be much better to simply maintain one single version of your code
(all in prototype form of course) and then to use my unprotoize tool to
unprotoize it on the fly (perhaps via commands in your Makefile) when you
need an unprotoized version.  That way, you won't end up with code that
contains two different "function headers" for each function.  Anytime you
have such a pair, you have to worry that they may diverge (over time) due
to maintenance activities, and thus become inconsistant with one another.
Also, if you avoid code which looks like the code in the latter part of your
example, you won't end up with code that protoize and unprotoize can no
longer process effectively (due to the rampant and excessive use of
preprocessing directives).