gnu@hoptoad.uucp (John Gilmore) (12/23/87)
karl@haddock.ISC.COM (Karl Heuer) wrote: > Can you really find a lot of examples of code that will be broken (not just > deprecated) by the new standard? No fair using code that was already > nonportable under K&R but just happened to work on your compiler. > > The only one that springs to my mind is mktemp("fooXXXXXX") (because it's no > longer safe to assume that string literals are writable). I have been porting 4.3BSD through gcc and finding a bunch of things. Many are nonportabilities -- preprocessor abuse and referencing members of other structures are the most common -- but some are not. One that comes to mind is functions that do: foo() { extern int errno; errno = 0; ... } bar() { if (errno) ... } ANSI C defines the "extern int errno;" to be local to foo(), so bar() must redeclare errno before it can use it. K&R defined it to be global. Another is that various programs used the identifier "signed". Another is programs that had unbalanced quotes inside #if 0. Another is programs that do: typedef int flag; foo(flag) int flag; {...} which has gotten hard to parse in ANSI C and is now disallowed. I can show you Unix source code that uses all these features. I will probably end up writing a paper for Usenix about it... -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com I forsee a day when there are two kinds of C compilers: standard ones and useful ones ... just like Pascal and Fortran. Are we making progress yet? -- ASC:GUTHERY%slb-test.csnet
throopw@xyzzy.UUCP (Usenet Administration) (12/25/87)
> gnu@hoptoad.uucp (John Gilmore) > karl@haddock.ISC.COM (Karl Heuer) wrote: >> Can you really find a lot of examples of code that will be broken (not just >> deprecated) by the new standard?> > [... 1) extern scopeing rules made more regular ...] > [... 2) collisions with new keywords ...] > [... 3) #if 0 elision of text not composed of proper tokens ...] > [... 4) prototype parsing fallout impacts typedef use ...] > I can show you Unix source code that uses all these features. I don't doubt it. But none of these seem hard to diagnose or fix, and are of the level of problem one could run into in a new implementation of a K&R compiler simply not based on a pcc descendant. Also, while I don't doubt the existance of these problems, I wonder about their prevalence. So: my opinion is still that this doesn't show ANSI C to break code much worse than any new independant implementation of C could do, regardless of the standard chosen. > I will probably end up writing a paper for Usenix about it... I look forward to it. Such a paper will doubtless be of tremendous value. -- There are some forms of insanity which, driven to an ultimate expression, can become new models of sanity. --- Bureau of Sabotage {Frank Herbert} -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw