Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!texsun!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Distinguished pointers (was Re: Weird syscall returns)
Message-ID: <25388@sun.uucp>
Date: Tue, 11-Aug-87 20:27:45 EDT
Article-I.D.: sun.25388
Posted: Tue Aug 11 20:27:45 1987
Date-Received: Fri, 14-Aug-87 01:49:24 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1847@ttrdc.UUCP>
Sender: news@sun.uucp
Lines: 85

> < It's all wrong anyway -- in C, '\r' and '\n' represent distinct
> < (whitespace) characters.
> 
> What is an implementation of C supposed to do on an OS/machine/character-code
> combination that doesn't have the foggiest that there is such a thing
> as distinct "new line" and "carriage return" characters?

1) Give up in despair.

2) Fake it.

What they are NOT supposed to do, under ANY circumstance, is to make '\r' and
'\n' be the same thing!  Doug is right; they *are* distinct characters.  From
K&R:

	2.4.3 Character constants

	   Certain non-graphic characters, the single quote ' and the backslash
	   \, may be represented according to the following table of escape
	   sequences:

		newline		NL (LF)		\n
		horizontal tab	HT		\t
		backspace	BS		\b
		carriage return	CR		\r
		form feed	FF		\f
		backslash	\		\\
		single quote	'		\'
		bit pattern	<ddd>		\<ddd>

And from the ANSI C standard:

	2.2.2 Character display semantics

	   The *active position* is that location on a display device where the
	next character output by the "fputc" function would appear.  The intent
	of writing a printable character (as defined by the "isprint" function)
	to a display device is to display a graphic representation of that
	character at the active position and then advance the active position
	to the next position on the current line.  The direction of printing is
	locale-specific.  If the active position is at the final position of a
	line (if there is one), the behavior is unspecified.

	   Alphabetic escape sequences representing nongraphic characters in
	the execution character seet are intended to produce actions on display
	devices as follows:

	...

	\n (*new line*) Moves the active position to the initial position of
	   the next line.

	\r (*carriage return*) Moves the active position to the initial
	   positiion of the current line.

	...

	   Each of these escape sequences shall produce a unique
	implementation-defined value which can be stored in a single "char"
	object.  The external representations in a text file need not be
	identical to the internal representations, and are outside the scope of
	this Standard.

On top of all this, having '\n' and '\r' be the same character violates the
Principle of Least Surprise, at least if the system uses ASCII (which I presume
OS9 does).

> From the looks of the discussion here, I'd gather that OS9 is just such a
> beast and its C compiler is making the best of this brain damaged situation
> that it can.

Uh-uh.  No way.  They had no excuse; they screwed up.

If they could, in any way, cause a display device to do the aforementioned, and
can represent these instructions to the display device in a file, they should
have arranged that the C library produce the appropriate instructions on
output.  If they couldn't do that, then they either shouldn't have implemented
C ("give up in despair") or they should have had '\n' be LF (i.e., '\012') and
'\r' be CR (i.e., '\015'), and had the *C library* act the same way when told
to output either character ("fake it").

In other words, it really *ain't* C.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com