ANSI C and the C Pre-Processor

[Henry Spencer]

>> Great. Another tool that's nearly vital for writing C, but not available
>> on most (all) non-Unix systems. Anybody got pointers to a public domain
>> m4?
>> 
>> 	<mike
>
>Anybody got pointers to a sane ANSI committee?  We just got a C compiler
>on CSUOHIO.BITNET (VM/370) and I intend to port quite a few of my compatible
>(i.e. not based on Unix peculiarities) programs.  If the ANSI committee
>thinks I'm going to use m4 on Unix and lose ALL portability, they've another
>think coming.

My personal impression is that the committee is saner than most of the
people flaming on this issue.  If they say "if you want a general-purpose
macro processor, use m4", all this means is that they are not able to solve
all the world's problems.  At some point, it is necessary to give up and
say "the tool we are trying to settle on is not powerful enough to solve
your problem".  Otherwise they never produce a standard, since the number
and complexity of problems that people would *like* their tool to solve
tends to grow without bound.

The committee, as nearly as I can see, is *not* crazy and is quite concerned
about portability.  They have simply judged that the problems that are under
discussion are (a) sufficiently uncommon, (b) sufficiently ill-understood,
and (c) sufficiently difficult, that attempting to solve them in the C
standard is inappropriate.  I agree.

Bear in mind that we do not **WANT** a C standard committee that is bent
on solving every possible problem.  The result would look nothing like C.
This has happened to other languages; ever looked at some of the recent
output from the ANSI BASIC effort?  If you are a serious C user, it is
appropriate for you to thank whatever gods you believe in that the ANSI
C committee hasn't gone that way.
-- 
	"If you ask for the moon, you may get the shaft instead."

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry