ANSI <--> K&R conversion utilities - COMMING SOON

[Marshall Cline]

In article <5472 at goofy.megatest.UUCP> djones at megatest.UUCP (Dave Jones) writes:
>> In article <229 at pink.ACA.MCC.COM> rfg at pink.aca.mcc.com.UUCP (Ron Guilmette) writes:
>>>Who wants to go backwards?
>It's the implied concept of backwards and forwards is backwards.
>Assuming that you like ANSII-C better than C, one wants an (ANSII-C)-to-C
>compiler so that one can make the "forward" step to writing in ANSII-C
>rather than in C.
>There are lots of C compilers around. If we had just one ANSII-C to C
>compiler, we would then have lots of ANSII-C-to-machine-code compilers.
>I could use an ANSII-C-to-C compiler.
>It's the same reason that cfront compiles C++ into C.

Actually, I think going "backwards" will be much more important in a few
years than it is now (think about it -- that sounds "backwards").

The reason is:  Right now we have a higher percentage of K&R code, so most
of our conversion will be K&R --> ANSI.  In a few years (months? days?),
people will be developing good, decent, useful, necessary, exciting things
in ANSI-C.  When this happens, those of us who still use K&R compilers
(which will probably be a lot of us) will have to bring the new code
"backwards" to the K&R style.

In short, if we don't have an _AUTOMATED_TOOL_ to _EFFECTIVELY_ and
_RELIABLY_ convert ANSI to K&R, "for portability's sake" we'll be
tempted to write _everything_ in K&R C, short-circuiting the advantages
of the Standard.

Marshall

PS: I still haven't gotten many e-mail responses.
Anyone have any great ideas, please send them to me -- I'll post results.

--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline at sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W at CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591