Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: Macro names imbedded in pp-numbers [repost]
Message-ID: <11147@riks.csl.sony.co.jp>
Date: 20 Nov 89 01:35:29 GMT
References: <11134@riks.csl.sony.co.jp> <1989Nov17.171025.18983@utzoo.uucp>
Reply-To: diamond@ws.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 16

In article <1989Nov17.171025.18983@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

>2.1.1.2 item 7 yields:  "Each preprocessing token is converted into a
>token."

Argh; you're right.  OK, next question:  if a program violates 2.1.1.2,
is it necessary to issue a warning?  I think not; 2.1.1.2 doesn't say
"constraints."  Therefore a macro imbedded in a pp-number results in
undefined behavior, and my processor is allowed to expand the macro,
right?  (I hope.)

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  Should the preceding opinions be caught or     |  James Bond asked his
  killed, the sender will disavow all knowledge  |  ATT rep for a source
  of their activities or whereabouts.            |  licence to "kill".