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
That is one big shift LOL!
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.
The conditional statement's expression will always be true. Maybe
*always* taking that path does not break anything.
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
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)
Not my decision. He may have good skills that I don't see.
Obviously, but that should have happened months ago (again this is a management issue outside my scope)
too late
He's a hardie. He may be a good hardie, Ich weiss nicht!
tim
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.
I did not say this. You have attributed it wrongly.
anyhow,I don't disagree with 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
possibly
tim
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
And perhaps closer to the truth. But when someone it put on trial, I'd like to know the whole story.
Could be leftovers from development tests.
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.
tim wrote: ...
tim wrote about a bug found by lint:
Dan Henry wrote:
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.
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
|| 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 ...
... 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.
This is true in way too many cases.
-----
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.
It sounds like he should be elsewhere.
Thad
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" schreef in bericht news: snipped-for-privacy@speakeasy.net...
Yes, but I didn't trim what Tim wrote. He trimmed his own text ;)
[snip]
Does anyone know of a free lint for C++?
- Tom
PC-lint from
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
Regards,
-=Dave
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
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
Isn't C kind of assembler?
Andreas
Have something to add? Share your thoughts — no account required.
Ask the community — no account required