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.