Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!eagle!icdoc!cam-cl!am
From: am@cam-cl.UUCP
Newsgroups: comp.lang.c
Subject: '\r' == '\n' (was: Distinguished pointers)
Message-ID: <1041@jenny.cl.cam.ac.uk>
Date: Mon, 10-Aug-87 10:46:49 EDT
Article-I.D.: jenny.1041
Posted: Mon Aug 10 10:46:49 1987
Date-Received: Sun, 16-Aug-87 18:41:48 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP>
Reply-To: am@cl.cam.ac.uk (Alan Mycroft)
Organization: U of Cambridge Comp Lab, UK
Lines: 25

In article <1547@watcgl.waterloo.edu> kdmoen@watcgl.waterloo.edu (Doug Moen) writes:
>This isn't pretty, but it solves your problem (of '\r' == '\n')
>	switch ( getchar() )
>	{
>	......
>	case '\n':
>#if '\r' != '\n'
>	case '\r':
>#endif
>		common code for the "enter" morpheme
>	......
>	}
Yes, it does look right doesn't it?  BUT, the dpANS document would
make this illegal (or rather non-strictly conforming) in that an
implementation is quite at liberty to use different character codes
in the pre-processor than in the compiler. (See footnote in the OCt 86
public review draft).
 [Yes, I think this is crazy too, I suppose the committee are endorsing
  "existing practice".  It allows compiler vendors to supply one
   pre-processor regardless of whether the 'compiler proper' is
   being used as a cross-(character-set)compiler.
   Of course, the pre-processor and compiler *should* use the same tables.
   Send in your complaints about this to ANSI before it is too late!]
I do not remember ANSI requiring '\n' != '\r' either although
they probably do.