Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: Roff in C (moved from net.sources)
Message-ID: <6890@brl-tgr.ARPA>
Date: Tue, 1-Jan-85 22:28:27 EST
Article-I.D.: brl-tgr.6890
Posted: Tue Jan  1 22:28:27 1985
Date-Received: Thu, 3-Jan-85 03:45:35 EST
References: <1158@ut-ngp.UUCP>
Organization: Ballistic Research Lab
Lines: 48

> This difference of opinion points up a very interesting problem: in testing
> the original "roff.c" I was not using the PCC compiler, but used two others
> instead -- DeSmet's C88 and CI-C86 on an IBM PC.  Both behaved exactly the
> same way -- *any* request (dot command) caused the input text to be discarded.
> However, it does *not* have this effect under PCC, as Tim points out.  I found
> out why:
> 
> Here's the offending code:
> _____________________________________________________________________________
> int
> suck()
> {
> 	for (;;) {
> 		c=getc(File);
> 		if (!iscntrl(c) && c!='\013' && c!='\f' && c!='\r') return c;
> 	}
> }
> ____________________________________________________________________________
> 
> and here's how the manual defines "iscntrl()":
> 
> iscntrl             c is a delete character (0177) or ordinary
>                     control character (less than 040).
> 
> BOTH of the stated compilers failed to interpret "ordinary" in the same way
> as the PCC routine of the same name -- they return TRUE if the code is less
> than octal 040.  As written, then, with this interpretation, newlines are
> never returned, and the text is lost.  PCC, however, excludes newlines,
> backspace codes, carriage return codes and a few others, presumably because
> they are not "ordinary."  
> 
> This says something fairly awful about "portability."

This says something fairly awful about available C implementations!

"ordinary" in the description of iscntrl is not an additional qualifier
but an explanatory one.  iscntrl( c ) should return non-zero for c in
{ 0, 1, ..., 036, 037, 0177 } and zero for c in
{ 040, 041, ..., 0175, 0176 }.  It is illegal to supply any other value
of c to the macro/function, although most implementations permit EOF (-1).

The "suck()" routine as written (apart from lack of declaration of the
variable `c') has redundancy in the condition, since c cannot equal any
of the three explicit control characters if it does not pass iscntrl().

"PCC" has nothing to do with the ctype macros; they are defined in
/usr/include/ctype.h (or equivalent on non-UNIX) and usually use a table
loaded from the standard C library.