A lint classic

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

After months of nagging, one of me colleagues
eventually got around to looking at the 'lint' errors
in his 'c' code (which the rest of us are supposedly
relying upon as working).

As well as the expected problems such as:

if (byte_var < 0x200).....

and

if ( var && 0xf0 )...

was the incredible (I thought)

new_var = var << 16000;  !!!

he looked at this line for a good 10 minutes before
declaring that he had no idea what it was really meant
to be doing.  Personally I can't recall having seen such
a stupid line of code ever left in *working* code.

Disappointingly, having proved the worth of this tool,
he thinks this is job done and that he doesn't have to
use it again.  He's in the wrong job (and perhaps, so
am I).

tim






Re: A lint classic
In comp.arch.embedded

Quoted text here. Click to load it

That is one big shift LOL!

Re: A lint classic

Quoted text here. Click to load it

As long as byte_var is truly a byte, the conditional statement's
expression will always be true.  Maybe *always* taking that path does
not break anything.

Quoted text here. Click to load it

The conditional statement's expression will always be true.  Maybe
*always* taking that path does not break anything.

Quoted text here. Click to load it

When the shift distance is greater than the width of var, the result
is undefined, but probably zero.  Maybe new_var being zero (or
anything else) does not break anything.

Quoted text here. Click to load it

His job (employment) *should* be done.  The offending code should be
fixed or removed.  The offending author should be "fixed" (so he does
not procreate) and removed.  Well, OK, just removed -- the fellow is
apparently clueless.

--
Dan Henry

Re: A lint classic

Quoted text here. Click to load it

Who cares.  It is an unnecessary ambiguity that shouldn't have
been there, that someone else will have to sort, when (if) the guy is
off long term sick with something as simple as a broken arm (as
he drives 120 kms to work each day this will be all it needs)

Quoted text here. Click to load it

Not my decision.  He may have good skills that I don't see.

Quoted text here. Click to load it

Obviously, but that should have happened months ago
(again this is a management issue outside my scope)

Quoted text here. Click to load it

too late


He's a hardie.  He may be a good hardie, Ich weiss nicht!

tim




Re: A lint classic
Quoted text here. Click to load it

How can you tell from 3 lines out of ????? - and perhaps his
system runs like a bloody miracle and surpasses anything known
to mankind ;)

Okay, sounds unlikely, but still.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)












Re: A lint classic

Quoted text here. Click to load it


I did not say this.  You have attributed it wrongly.

anyhow,I don't disagree with it

Quoted text here. Click to load it

It isn't the number of error that is the clue (and these were
just a few samples BTW).

It's the general "couldn't care less about fixing them" attitude
that's the point

Quoted text here. Click to load it

possibly


tim



Re: A lint classic

Quoted text here. Click to load it

Actually, he quoted correctly.  In this message your (tim's) words are
one quote deep, Frank's are two, Dan's are three, your earlier quote
would be four.  The quotation in question is three levels deep (Dan's).
  When you look at Frank's message, he had included earlier quotes from
you, which had the next nesting level, which you trimmed.

Quoted text here. Click to load it

It sounds like he should be elsewhere.

Thad


Re: A lint classic

Quoted text here. Click to load it

True, but it is considered bad form to leave in "tim wrote" while
trimming what tim wrote. Uninformed readers may assume that the
words following "tim wrote" are by tim.

IIRC, there was a court case where a DA made that false assumption.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
We've slightly trimmed the long signature. Click to see the full one.
Re: A lint classic
"Guy Macon" <http://www.guymacon.com schreef in bericht
Quoted text here. Click to load it

Yes, but I didn't trim what Tim wrote. He trimmed his own text ;)

[snip]

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)






Re: A lint classic

Quoted text here. Click to load it

I saw the wink, but seriously, in my experience, when I've seen this
lack of attention to detail and that kind of attitude demonstrated,
the results have never been good.

I'd rearrange your conjecture slightly: "a bloody miracle his system
runs" ;)

The errors are so blatantly obvious you wouldn't need lint to find
them.  A simple code inspection would have caught them.

Error #1: Some might consider it subtle.  I don't.
Error #2: Perhaps a typo.  I'll forgive it.
Error #3: WTF!!??  Inexcusable.

Thinking his job is done: No team needs a prima donna.  Code, once
linted is (mostly) easy to keep linted.  There is no reason to not use
it again.

All my own opinions, of course.

--
Dan Henry

Re: A lint classic
Quoted text here. Click to load it

And perhaps closer to the truth. But when someone it put on trial,
I'd like to know the whole story.

Quoted text here. Click to load it

Could be leftovers from development tests.

Quoted text here. Click to load it

Same here ;) Perhaps it is not for him to decide how to spend his
time. Or like the situation where you know there are still bugs/flaws
but you've chosen to let them sit where they are.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)








Re: A lint classic
tim wrote about a bug found by lint:
Quoted text here. Click to load it


Why would it always be true?  It seems to me that the statment
as written is equivalent to
    if (var && true)
which is equivalent to
    if (var) ...

If var is true, so is 0xf0.  If var is false, the && operator will
not evaluate the right operand, and the expression is false.

If the operator were || (bitwise or), the expression would always be
true.

Quoted text here. Click to load it

I don't think it's reasonable to say "probably zero".  Throwing away
high-order bits of the shift count is a common implementation.  An
implementation that did this would treat a shift count of 16000 (0xe380)
as a shift count of zero, so the value assigned to new_var would be the
original value of var.  Other iplementations might well return zero
due to the shift count exceeding the maximum.  Other implementations
could return any arbitrary or effectively random result.

It's best just to leave the description as "the result is undefined".

Eric

Re: A lint classic
On 29 May 2004 19:13:55 -0700, Eric Smith

Quoted text here. Click to load it

   || is the LOGICAL "or" operator, not the bitwise or. (vs. | which
IS bitwise or). Such errors are easy to make in C, and so it's no
wonder ...

<Warning, type="flamebait", topic="religion">

... people have so many problems with C, "the most dangerous language
in the world."
   In Pascal and other "strongly typed" languages, many such errors
wouldn't get past the compiler. It's unfortunate that lint is still a
separate program instead of being part of every C and C++ compiler.
Thirty years ago, computers weren't as fast and powerful as they are
nowadays, and I can see that as an excuse for lint and the compiler to
be separate programs, but not now.

</>

Quoted text here. Click to load it


   This is true in way too many cases.

Quoted text here. Click to load it

-----
http://mindspring.com/~benbradley

Re: A lint classic

Quoted text here. Click to load it

Does anyone know of a free lint for C++?

- Tom



Re: A lint classic
On Sun, 30 May 2004 10:29:18 -0400, "Thomas Carley"

[...]
Quoted text here. Click to load it

PC-lint from www.gimpel.com.

OK, it's not free, but if you're paid to write C or C++ code, it'll
pay for itself in a week.  If you're not paid, it'll take longer --
probably a month.

The only free lint I know anything about is splint at www.splint.org,
but I don't know if it handles C++...

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: A lint classic

Quoted text here. Click to load it

Ack.


It didn't handle "embedded" specifics when I looked at Splint 2003. I
wrote about the problems repeatedly, look at Google groups and the
Splint mailing list archives.

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: A lint classic
Quoted text here. Click to load it

It doesn't.

--
"I'm a war president.  I make decisions here in the Oval Office
 in foreign policy matters with war on my mind." -         Bush.
We've slightly trimmed the long signature. Click to see the full one.
Re: A lint classic

Quoted text here. Click to load it

Perhaps he is from the future and forgot that our computers
don't have 65536-bit words?  :)


Re: A lint classic
...
Quoted text here. Click to load it

I've SEEN that code before: it used the most
stable 'clock' in the h/w to create a delay!!


Re: A lint classic

Quoted text here. Click to load it

Until the new compiler release optimizes away the statement silently.

Delays shouldn't be done by HLL loops. Only assembler code or hardware
counters should be used.

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Site Timeline