[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RISKS: Princeton discovers another Netscape security flaw
On 25 Mar 1996 Paul_Koning/US/3Com%[email protected] wrote:
> ses @ tipper.oit.unc.edu (Simon Spero wrote:
> >A pound to a bucket of ferrets this is another visit from our good friends
> >Capt. Overrun and the static buffers, in which case it's more an indictment
> >of C
>
> So? I agree that it's essentially impossible to write reliable code
> in C, just as in assembly language. Actually, it's easier in assembly
> language because then you KNOW you have to do all the work
> yourself, while C misleads you into thinking it does some of the
> work for you when in fact it does not.
Well, what would you suggest then ? Some mental masturbation like C++ ?
<end religious jab> :-)
I have found over the years, that C, just like anything other language,
has it's quirks and foibles. malloc() calloc() alloc() and realloc() are
known problems that go way back to the early days on the DEC; not to
mention odd sized structure members can cause phase errors during
compilation that never show until runtime.
>
> That doesn't affect the point at all, though.
>
> The job of doing something like what Java claims to do correctly
> is basically equivalent to the job of creating an A2 grade operating
> system. (Don't bother looking for any, as far as I know the designation
> A2 doesn't even exist anymore because it is still beyond the state
> of the art. It means "verified implementation", i.e., the implementation
> -- not just the design as in in A1 -- is provably correct. Note that
> a strict interpretation of this would involve holding not just the code
> itself but also the tools that act on it -- like compilers, and microcode
> in machines that have it -- to A2 standards. If you wonder why, consider
> the famous Unix login hack from many years ago that involved
> a hack in the C compiler.)
>
> paul
>
I will agree with you here. What I mildly take issue with is that the C
compiler shoulders the blame for faults that lie in the libraries and OS
- just to start pointing fingers. DOS is famous for it's lack of system
integrity when it comes to file and memory management - yet the standard
library can do no more than what the target OS allows to take place.
Thus the language get's blamed for shortcommings in an environment. Also,
consider that many applications these days are built using third part
support.
Now we have the added dimension of someone else's code on top of our own,
plus the compiler, plus the libraries, plus the OS. It's not a pretty
picture, especially since we trust "packaged goods" too much.
C itself is only composed of some 28 keywords, plus some extensions and a
simple grammer. I personally will trust the the compiler first before I
would trust the libraries linked, just based upon the simplicity of the
language - failing some glaring error in the parser.
> !-----------------------------------------------------------------------
> ! Paul Koning, NI1D, C-24183
> ! 3Com Corporation, 1-3A, 118 Turnpike Road, Southborough MA 01772 USA
> ! phone: +1 508 229 1695, fax: +1 508 490 5873
> ! email: [email protected] or [email protected]
> ! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
> !-----------------------------------------------------------------------
> ! "The only purpose for which power can be rightfully exercised over
> ! any member of a civilized community, against his will, is to prevent
> ! harm to others. His own good, either physical or moral, is not
> ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
>
...Paul
-------------------------------------------------------------------------
"Faced with the choice between changing one's mind and proving that there
is no need to do so, almost everybody gets busy on the proof"
-- John Kenneth Galbraith
"Success is attending a funeral as a spectator"
-- E. BonAnno
-------------------------------------------------------------------------