lkml.org 
[lkml]   [1999]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.082 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site