Messages in this thread | | | Date | Fri, 7 May 1999 01:25:31 -0400 | From | Arvind Sankar <> | Subject | Re: fork() Problem? |
| |
On Wed, May 05, 1999 at 09:28:22PM -0400, Richard B. Johnson wrote: > > 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.
exactly. You don't.
> > 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
If you're a sample of the kind of reviewers they use, the pentagon's software would probably launch a pre-emptive nuclear strike against Washington, DC.
> 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.
I thought you just said that (2) isn't allowed? `...make damn certain ... generate the code specified.'
> > 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.
The operative clause being `who has knowledge of the language'. Clearly this doesn't apply to you.
> > 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.
duh? `The problem is that it may work'? There isn't much in knowing why a program compiles. A little more (but not much) interesting is figuring out why it doesn't.
> > 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.
Methinks it very bad practice to depend on whether char is signed or unsigned.
> > 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.
m. I don't see this at all. If it's an error in somebody else's code, presumably his inputs/outputs aren't implemented properly by him (an error with no external effects isn't much of an error), and it should be fixed by him, not by everybody calling his code.
> > 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)
Parentheses do not introduce sequence points.
> > Regardless of the flames or comments I will have nothing further > to say about this.
Yeah, right.
-- arvind
- 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/
| |