Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!fluke!mce From: mce@tc.fluke.COM (Brian McElhinney) Newsgroups: comp.sys.mac.programmer Subject: Re: LSC almost gets it right. Message-ID: <5125@fluke.COM> Date: 9 Sep 88 20:06:23 GMT References: <5077@fluke.COM> <526@bruce.oz> Sender: news@tc.fluke.COM Organization: SRS Recursive Software, Castrovalva, WA Lines: 34 In article <526@bruce.oz> conybear@bruce.oz (Roland Conybeare) writes: >From article <5077@fluke.COM>, by mce@tc.fluke.COM (Brian McElhinney): >> Documenting a bug does not make it a feature (the Require Prototypes option >> should *require* prototypes for *all* routines; anything less is a bug). > > Ahem! My version of LSC (2.01) when told to "require prototypes", >complains about all unprototyped calls, *including* toolbox traps. > So while I would agree that not providing prototypes for toolbox traps >is an omission, I would not call it a bug. Ahem on myself. I should have mentioned I'm using LSC 3.0. Obviously this has changed since 2.01. Perhaps LSC 3.1 will have true ANSI prototypes??? Of course, I'd rather have THINK spend their time on a C++ compiler. And will the debugger be updated to let you look at all stack frames? LSC's is the first symbolic debugger I have seen that only lets you look at the top frame. Surely I'm not the only one who digs into calling stack frames in search of the Last Bug... >P.S. and yea verily, doth lint, in its wisdom, deign to check calls to > functions, where such calls be made through pointers? Only thy return values. But what else could a K&R lint do? A true ANSI C compiler (when there is such a thing) would have to check parameters as well. > I wish (Oh, how I wish) that LSC would allow me to prototype either types or > declarations Oh yes. But at least LSC 3.0 does something with the prototypes it allows! MPW C (the last non-beta version) would except ANSI prototypes, and then silently ignore them. I'm sure this feature was documented too... Brian McElhinney mce@tc.fluke.com