rchampe@hubcap.UUCP (Richard Champeaux) (01/27/89)
I just bought Gimple Software's Lint and I'm using it with Aztec C.
I've come across some problems. First off, the include file "functions.h"
and library definition file, "manx.l" that came with Lint didn't agree on
about 30 of the functions return value types. I used the disk based update
of the RKM for 1.2 to correct them. It turned out that manx.l agreed with
the RKM, and functions.h didn't. functions.h declared the return types to
be shorts when the RKM claimed they were long or BOOL. That was easy
enough to fix, but it took some time.
My current problem is with InitBitMap(). I've been compiling with
+l because I was too scared about getting the arguments wrong; but now
that I have Lint to tell me when my arguments are wrong, I decided to
do things right. When I ran a program I've been working on through Lint,
it told me that the arguments I was passing to InitBitMap() were shorts
instead of longs, which manx.l claims they should be. Just to be sure,
I looked InitBitMap up in the disk based RKM, it said that depth is a
BYTE, and width and height are SHORT.
Which is correct? manx.l or the RKM? When I was compiling with +L
it didn't matter because everything gets type cast to a 32 bit int when
they're passed to functions. But if I compile without the +L, the wrong
type will cause all kinds of Hell.
I realize that they could both be right; Aztec's library stubs might
require longs even though the library function might only need BYTEs and
SHORTs, but I just want to make sure.
Other than the few minor, fixable problems I've had, I really like Lint.
Its kind of slow, but it already caught an error (other than the argument
types) that got by the compiler.
Thanks for any help.
Rich Champeaux
Clemson Universityjesup@cbmvax.UUCP (Randell Jesup) (01/28/89)
In article <4218@hubcap.UUCP> rchampe@hubcap.UUCP (Richard Champeaux) writes: >When I ran a program I've been working on through Lint, >it told me that the arguments I was passing to InitBitMap() were shorts >instead of longs, which manx.l claims they should be. Just to be sure, >I looked InitBitMap up in the disk based RKM, it said that depth is a >BYTE, and width and height are SHORT. > Which is correct? manx.l or the RKM? When I was compiling with +L >it didn't matter because everything gets type cast to a 32 bit int when >they're passed to functions. But if I compile without the +L, the wrong >type will cause all kinds of Hell. All system functions linked with the commodore supplied amiga.lib require longs be passed on the stack. All library functions (that we wrote) require parameters in registers. We may only use part of the register, as in the case you gave of InitBitMap, in which case it will be listed in the RKM as SHORT (obsolete, replace with WORD) or BYTE, etc. I don't know whether manx's stubs are our stubs, but I think they are the same. I'd test it if I were you. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
cks@ziebmef.uucp (Chris Siebenmann) (02/01/89)
Regardless of Manx's documentation, you have to call all their Rom
routine stubs with 32-bit parameters. The return values are also
'really' 32-bit quantities, but you can cheat and call them 'short'
sometimes without harm. Also, watch out for other mistakes in their
functions.h file; they made a couple of whoppers.
While Gimpel Lint is one of those programs which really cry out for
lots of memory, a 68020, and a fast HD, it's also one of the more
important utilities for Amiga C programmers, especially Aztec C
programmers. It's relatively cheap and works pretty damn well; I think
every commercial developer working in C should get and use a copy.
ComicSetter lints cleanly ... does YOUR program?
--
"Though you may disappear, you're not forgotten here
And I will say to you, I will do what I can do"
Chris Siebenmann uunet!{utgpu!moore,attcan!telly}!ziebmef!cks
cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cksdillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/04/89)
:programmers. It's relatively cheap and works pretty damn well; I think
:every commercial developer working in C should get and use a copy.
:
: ComicSetter lints cleanly ... does YOUR program?
:
:cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
That's kind of funny in itself though. For example, I have never
used lint and will never use lint ... it barfs on too many valid
practices and generally does not keep up with the C standard.
The main thing that I wind up saying over and over to people is
that there is no easy solution for the experieenced programmer no matter what
language he/she uses (so far). That is, the programmer who writes very strict
code and uses lint will have just as many screwy bugs in his stuff than
the programmer who doesn't. Using various code-checkers such as lint
or switching to 'object oriented languages' as a means of ensuring that the
programmer writes more correct code is a psychological trap ... in
many cases it does just the opposite without the programmer knowing it.
The ultimate errorlessness and reliability of your code depends
solely on how well you can lay down the code.
Another common misconception is that forcing structure and/or
checking structure will make a better programmer out of the beginner. It
doesn't. It *might* be helpful removing simple-stupid (cosmetic) coding
mistakes ... things the experienced programmer almost never make, but this
by no means covers all the problem areas. My guess is that, in terms of
time, lint will catch maybe 1-10% of a beginner's mistakes and 0-3% of
an experienced programmer's mistakes. That's TIME, not # of mistakes. It
takes me a couple of seconds to find/fix stupid simple mistakes while it
might take me hours to find/fix algorithmical mistakes.
In programming, experience counts in a big way and many shortcut
routes simply prolong the time required to gain it.
-Mattcg@myrias.UUCP (Chris Gray) (02/10/89)
In article <8902040530.AA29151@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
Well, I've actually omitted everything that Matt said - I wasn't going to be
able to type in enough to keep postnews happy.
Basically, Matt says that he doesn't see much value in things like lint and
strongly typed/modular languages for "experienced" programmers. (At least
that's the way I read it.)
I couldn't disagree more strongly. I want the computer to do the grunt-work,
not me. I'm human - I'm fallible - I forget things.
I just wanted to add my little bit to what is (unfortunately) likely to
grow into a huge and long argument. Please folks, can we keep these
religious arguments out of the newsgroups and in private mail, where they
belong?
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg