On 25 Mar 1996 Paul_Koning/US/3Com%3COM@smtp1.isd.3com.com 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: paul_koning@isd.3com.com or paul_koning@3mail.3com.com ! 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 -------------------------------------------------------------------------