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').