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: <26030@sun.uucp>
Date: Wed, 19-Aug-87 15:10:13 EDT
Article-I.D.: sun.26030
Posted: Wed Aug 19 15:10:13 1987
Date-Received: Sat, 22-Aug-87 03:56:17 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <503@sugar.UUCP>
Sender: news@sun.uucp
Lines: 25

> There is no "new line" character in ASCII. UNIX uses "line feed" as the new
> line character. OS/9 uses "carriage return". I'd say the 'C' language itself
> is suffering from parochialism here.

No, not really; this is no more parochial than using "0" (converted to the
appropriate type) to represent a null pointer.  In both cases, it is possible
to properly implement C; you just have to clear your mind of the notion that
the fact that "0" is used to represent a null pointer means that a null pointer
must consist of all zero bits, or that the fact that '\n' stands for LF means
that lines in the native OS's file system must end with an LF.

If OS/9 uses CR as the line-terminator character, the C I/O routines for OS/9
(i.e., "printf", "fputs", etc.) should translate LF into CR on output, and
translate CR into LF on input.  This may, of course, require them not to ignore
the "b" modifier on "fopen" modes, so that in "text" mode this translation is
performed and in "binary" mode it isn't, but that's life.

Of course this raises the question of what the C I/O routines should translate
CR to on output, or what should be translated to CR on input, but then if OS/9
doesn't provide a mechanism to "move the active position (of an output device)
to the initial position of the current line" they do, technically, have a
problem with implementing ANSI C, at least.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com