> This is *not* a bug. lint is WARNING you (caps mine) that this may have
> different results than expect. But the functionality behind the expression
> is a C design feature that has been there since day one. Any compiler that
> DOES execute the inside of the if() statement in the code you present would
> be buggy.
>
> --
> Manuel A. McLure KE6TAW <mmt@unify.com>
Lint _clearly_ states that it's an error.
> Finished LCLint checking --- 2 code errors found
Further, previous text states why. Any time I point out these things
I get a bunch of fanatical "tool gurus" responding that I don't
know what I'm talking about.
The 'C' language is just a tool. It is not a religion. It is also
not a means unto itself. In the "real world", I don't give a damn
about what you can get away with while using such a tool.
I'll bet a dollar that there are few that have even seen Commercial
Software that was reviewed by the FDA or DOD. If you want to pass
the muster, take a lesson.
The ONLY reason why the 'C' Language is now allowed instead of ADA
in Government end-user applications is because of persons like me
who specified and signed up to some minimum standards. These standards
say nothing about style, but make damn certain that the compiler(s)
to be used generate the code specified. This means that some sloppy
constructs are simply not allowed.
It is mandatory that bugs generated are either:
(1) Coding errors.
(2) Tool (compiler/linker) errors.
Both can be fixed, and the audit trail of the fixes can be well
established.
The first line of defense is writing clear code that can be understood
by anyone who has knowledge of the language being used.
Then the code is compiled or assembled. This is only the second step.
You don't even test it now. The problem is that it may work!
You need to know why it works and verify that.
Then the code is reviewed by an impartial machine, i.e., Lint and
anything it doesn't like is fixed. There are site-configuration
specifications that you and the Agency has signed up for (like
is char signed or unsigned, upon what functions can we ignore
the return value by default "printf()" comes to mind. This is the
third step.
The fourth step involves testing of the new function stand-alone,
something usually ignored by 'hackers'. This is a reason why
functions must have well-defined inputs and outputs. An error in
somebody else's code that blows up your function can't be allowed to
propagate. If it blows up your code, your code is broken.
After about 20 steps. The code is tested.
Eventually, selected sections are reviewed by people who think they
know more than you or me. If you can't defend whatever they think
they see, you go back to step one.
That said, the problem with:
if(a=b)
is that the value of a is not tested. 'a' got assigned the value of
'b', but only the assignment was tested, not the resulting value.
This, as I explained over and over again, is called a
"boolean test of assignment error". It is a real error because,
unless the machine crashed, it is always TRUE. This is what
Lint is complaining about. One needs to test the result. You
can do this by adding a sequence-point.
The obvious way:
a = b;
|_____ sequence point
if(a)
Or you combine expressions:
if( (a=b) )
|_______ sequence point (closed parens)
Regardless of the flames or comments I will have nothing further
to say about this.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/