roy@alanine.phri.nyu.edu (Roy Smith) (08/06/90)
I'm just starting to get into programming on the Mac. I'm using
Think C. What I can't seem to figure out is how to debug programs,
especially when it comes to tracking down pointer mistakes. For example, I
just tracked down a bug resulting from my doing "GlobalToLocal (point)"
instead of "GlobalToLocal (&point)". On a Unix system, lint would have
caught something like that. Think C seems to do some sort of built in type
checking with toolbox routines, but didn't catch this one. Any suggestions
for how to find stuff like that?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"oster@well.sf.ca.us (David Phillip Oster) (08/10/90)
In article <1990Aug5.195935.16500@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: >Think C. What I can't seem to figure out is how to debug programs, >especially when it comes to tracking down pointer mistakes. For example, I >just tracked down a bug resulting from my doing "GlobalToLocal (point)" >instead of "GlobalToLocal (&point)". Modern C's, particularly THINK C support prototypes. If you #include <MacProtos.h> #include <MacProtos5.h> then the compiler will catch bugs like the one that bit you. You should be able to get MacProtos.h & MacProtos5.h from any decent Mac software archive. -- -- David Phillip Oster - Note new signature. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
minich@d.cs.okstate.edu (Robert Minich) (08/17/90)
by roy@alanine.phri.nyu.edu (Roy Smith): | I'm just starting to get into programming on the Mac. I'm using | Think C. What I can't seem to figure out is how to debug programs, | especially when it comes to tracking down pointer mistakes. For example, I | just tracked down a bug resulting from my doing "GlobalToLocal (point)" | instead of "GlobalToLocal (&point)". On a Unix system, lint would have | caught something like that. Think C seems to do some sort of built in type | checking with toolbox routines, but didn't catch this one. Any suggestions | for how to find stuff like that? Use prototypes. THINK C knows the number and size of arguments for the toolbox but will take any types you like. For prototypes of the toolbox calls, ftp to: sumex-aim.standford.edu [36.44.0.6] login:anonymous password: <whatever> and in info-mac/lang you'll find: macmod info-mac 19748 Sep 16 1989 inside-mac-c-prototypes.hqx and use it for everything. It can head off problems you wouldn't otherwise catch. The only drawback is that you have to do lots of type casting in function calls where you send constants like 0 or -1 or whatever. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| There are no heroes -- |=(___)= | minich@a.cs.okstate.edu | We all wear gray hats. | U | - Ackphtth |
beard@ux5.lbl.gov (Patrick C Beard) (08/17/90)
In article <1990Aug16.213123.14437@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes:
#by roy@alanine.phri.nyu.edu (Roy Smith):
#| I'm just starting to get into programming on the Mac. I'm using
#| Think C. What I can't seem to figure out is how to debug programs,
#| especially when it comes to tracking down pointer mistakes. For example, I
#| just tracked down a bug resulting from my doing "GlobalToLocal (point)"
#| instead of "GlobalToLocal (&point)". On a Unix system, lint would have
#| caught something like that. Think C seems to do some sort of built in type
#| checking with toolbox routines, but didn't catch this one. Any suggestions
#| for how to find stuff like that?
#
# Use prototypes. THINK C knows the number and size of arguments for the
#toolbox but will take any types you like.
Ah, yes. But even with prototypes for the toolbox, if you aren't careful
to prototype all of your own routines, THINK C can still miss things. In
fact, even if you do prototype EVERYTHING, THINK C still doesn't warn you
about using unitialized variables, and other unsafe usages, nor does it
tell you about variables you aren't even using anymore.
Use MPW C++! I've passed THINK C objects that were written in a C++ compatible
style through MPW C++ and found things I would have never caught in THINK C.
Lint should be part of the compiler, not a separate pass. MPW C++ is the
closest thing I've seen. It's even good to pass regular C code through it
just to get that extra level of type checking (that's why it's so slow :)).
--
-------------------------------------------------------------------------------
- Patrick Beard, Macintosh Programmer (beard@lbl.gov) -
- Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey -
-------------------------------------------------------------------------------russotto@eng.umd.edu (Matthew T. Russotto) (08/17/90)
In article <6529@helios.ee.lbl.gov> beard@ux5.lbl.gov (Patrick C Beard) writes: > >Lint should be part of the compiler, not a separate pass. MPW C++ is the >closest thing I've seen. It's even good to pass regular C code through it >just to get that extra level of type checking (that's why it's so slow :)). But what about those of us who don't LIKE lint? If I wanted a nice, safe language that whined when I assign chars to unsigned chars, or complained when I passed a pointer to a routine expecting an integer (SetWRefCon, anyone), or complained when the end of a function was not reached, etc,etc, I'd use Pascal or something. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?