Messages in this thread | | | Date | Wed, 5 May 1999 21:28:22 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | RE: fork() Problem? |
| |
On Wed, 5 May 1999, Manuel A. McLure wrote:
> 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/
| |