Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 (Fortune 01.1b1); site graffiti.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ut-sally!ut-ngp!shell!graffiti!peter
From: peter@graffiti.UUCP (Peter da Silva)
Newsgroups: net.lang.c
Subject: Re: \"handy.h\"
Message-ID: <202@graffiti.UUCP>
Date: Mon, 16-Sep-85 08:16:20 EDT
Article-I.D.: graffiti.202
Posted: Mon Sep 16 08:16:20 1985
Date-Received: Sun, 22-Sep-85 06:04:30 EDT
References: <1133@brl-tgr.ARPA>, <148@graffiti.UUCP> <1357@drux3.UUCP>
Organization: The Power Elite, Houston, TX
Lines: 12

> Are you saying that defining EOL as '\0' is incorrect because it does
> not match exactly what your system does?

No, just saying that as far as I know, no O/S uses '\0' for end-of-line.
Also, every 'C' implementation that I have seen for systems that don't use '\n'
for end-of-line has translated-mode I/O that maps \n into whatever line/record
separators that are actually used. Including RSX (which doesn't have an end
of line character: each line is a record containing the length, line #, and
text). Basically, if you're going to give a sample handy.h file you might as
well make it a common one. Finally, if '\0' was EOL, you still couldn't use
it as such without redefining EOS (which is almost certainly going to be '\0'
for any vaguely portable 'C').