Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Another sizeof question
Message-ID: <14428@smoke.brl.mil>
Date: 11 Nov 90 08:45:15 GMT
References: <2654@cirrusl.UUCP> <14343@smoke.brl.mil> <2670@cirrusl.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <2670@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>In <14343@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>     In any case, we have been telling people for years that if they
>     want a macro processor they should use something like "m4" rather
>     than rely on cpp.
>Were UNIX the only environment to be considered, m4 could be considered
>a tolerable macro processor.

I said, "something like "m4"".  For example, use the one in "Software Tools".

>The *only* macro processor that comes close to being ubiquitous and a de
>facto standard is the one described by K&R.  This is why it's a loss
>that the standardization of C wasn't accompanied by the standardization
>of C's preprocessor as a stand-alone program.

The C preprocessor has never been a general-purpose macro processor, as
should be well known to anyone who has tried to use it as one.  Further,
it was never required to be implemented separately from the C compiler, and
indeed it was integrated into the compiler in a number of implementations.

I get rather tired of people saying that the C standard should have
mandated exactly the parochial little enviropnment that they happened
to grow up in.