lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: fork() Problem?
On Wed, 5 May 1999, Richard B. Johnson wrote:

> 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.

NO NO NO.. a IS what's tested (well, you could say b is, but it's
the same) and NOT the assignment. That's what people have been trying to
tell YOU.

That "your compiler is buggy" code you've pasted 1001 times will
not work under ANY C compiler known to man, as the logic is serverly
broken, and so it yours.

I must say with your completly flawed knowledge of even BASIC C
programming... were you a Microsoft employee that worked on the Windows NT
team?

-Dustin



-
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:2.205 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site