Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!uunet!stanford.edu!shap@shasta.Stanford.EDU
From: shap@shasta.Stanford.EDU (shap)
Newsgroups: comp.lang.c
Subject: Re: ANSI C/gcc1.39 question on Sys Vr4
Message-ID: <173@shasta.Stanford.EDU>
Date: 29 Apr 91 16:17:35 GMT
References: <1991Apr21.014544.16923@swsrv1.cirr.com> <59420@bigtex.cactus.org>
Organization: Stanford University Computer Systems Laboratory
Lines: 38

In article <59420@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes:
>In <1991Apr21.014544.16923@swsrv1.cirr.com>, toma@swsrv1.cirr.com
>	(Tom Armistead) wrote:
>> #if #machine(pdp11)
>
>> Can anybody tell me what the '#machine' is supposed to do?
>
>gcc works fine here.  AT&T screwed up.  Someone must have been on a
>stupid drug - there was no call for introducing that sort of
>incompatibility.

The #machine is related to the AT&T #assert extension, and indeed
someone was taking their stupid pills, because the last time I looked
both the #machine style hack and the #assert stuff were not ANSI
compliant.  What's REALLY dumb is that they could have done it just as
easily by using the preprocessor's leading-underscore namespace to
implement the same thing with complete compatibility.

The way it works is that you can say

	#assert machine pdp11

And later you can say

	#if machine(pdp11)

The word 'machine' is just a sample usage - both the predicate and the
condition appear to be user supplied identifiers of any kind.

Since this stuff is not ANSI compliant, can we please start a flame
war to remove these things from the source code?  It essentially
guarantees that all AT&T code is nonportable, and that a third-party C
compiler has to implement this non-ANSI extension to run successfully
on an AT&T V4 system (only if it wants to make use of header files, of
course, but still...).


Jonathan Shapiro