casey@CS.UCLA.EDU (08/28/88)
Just ran into a strange one here. Apparently the SR9.7 /usr/lib/cpp has problems outputting extremely long lines. When the imake program distributed with X.V11R2 tried to use /usr/lib/cpp to process the top level Imakefile, /usr/lib/cpp introduced newlines in its output lines where no newlines were present in its input lines. This is curious because the X.V11R2 installation document says that X.V11R2 has been successfully built on SR9.7. Someone must have a newer copy of /usr/lib/cpp than I do. Is this going to be fixed in SR10? I got things going by grabbing the 4.3BSD cpp and compiling it. This seems to be working fine. Casey
pato@apollo.COM (chc 02 rd) (08/31/88)
In article <15567@shemp.CS.UCLA.EDU> casey@CS.UCLA.EDU (Casey Leedom) writes: > > Just ran into a strange one here. Apparently the SR9.7 /usr/lib/cpp has >problems outputting extremely long lines. When the imake program >distributed with X.V11R2 tried to use /usr/lib/cpp to process the top >level Imakefile, /usr/lib/cpp introduced newlines in its output lines >where no newlines were present in its input lines. > . . . > >Casey 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. Joe Pato UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato Apollo Computer Inc. NSFNET: pato@apollo.com
casey@admin.cognet.ucla.edu (Casey Leedom) (09/01/88)
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. It took me over an hour to get the standard cpp from Berkeley compiled and working correctly. I had access to that source. What would someone 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. What is it? You think you can change anything in Unix randomly and still call what you end up with Unix? Get off it. That's not customer support. (And this isn't Unix - let's all hear it for ... `fixed in SR10' ...) Casey
pato@apollo.COM (chc 02 rd) (09/03/88)
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