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/