Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!husc6!mit-eddie!apollo!pato
From: pato@apollo.COM (chc 02 rd)
Newsgroups: comp.sys.apollo
Subject: Re: /usr/lib/cpp has trouble outputting long lines??
Keywords: /usr/lib/cpp, X.V11R2, imake
Message-ID: <3e3c26e9.12edf@apollo.COM>
Date: 2 Sep 88 23:12:00 GMT
References: <15567@shemp.CS.UCLA.EDU> <3e3050a4.12edf@apollo.COM> <15688@shemp.CS.UCLA.EDU>
Reply-To: pato@apollo.COM (Joe Pato)
Organization: Apollo Computer, Chelmsford, MA
Lines: 27

In article <15688@shemp.CS.UCLA.EDU> casey@cs.ucla.edu (Casey Leedom) writes:
>In article <3e3050a4.12edf@apollo.COM> pato@apollo.COM (Joe Pato) writes:
>> The sr9.7 /usr/lib/cpp intentionally breaks long lines.  This facility
>> was provided to avoid the problem that the 9.7 C compiler had with
>> reading input lines longer than 256 characters.
>
>  This isn't an acceptable answer.  Your compiler was broken, so you
>broke cpp also???  Your compiler doesn't even use /usr/lib/cpp for the
>most part!!!  At the *VERY* least, provide a switch to cpp to get it to
>give me unbroken output lines.
>

You are right.  There should have been a switch.  This behavior is no longer 
present in sr10.  (strictly speaking, cpp was not broken.  It still generated
code that was perfectly acceptable to the C compiler.  In fact if you had
macros that generated long output lines using this cpp was the only way to have
the C compiler accept the input)

>who didn't have access to that source do???  And where is the
>documentation of your change?  I don't see it in the cc manual page.
>

The documentation appeared in the release notes as a workaround for the C
compiler problem - which had been detected too close to the product ship date
to have the documentation appear in the regular manuals.

  Joe Pato                UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato
  Apollo Computer Inc.  NSFNET: pato@apollo.com