Re: Latest on Windoze Navy software

From: Bill Gunshannon (bill_at_cs.uofs.edu)
Date: 10/15/04 

Date: 15 Oct 2004 15:30:44 GMT

In article <jUPbd.37101$Z14.13678@news.indigo.ie>,
        "Tom Wade" <nospam@picard.eurokom.ie> writes:
>
> "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message
> news:2t83nvF1t1choU1@uni-berlin.de...
>
>> "It's a poor workman who blames his tools."
>
> I want to shave with a razor, I'll use a modern safety one, not an open
> cut-throat type. Yes, if I slice my jugular it's my fault, but I'm much
> more likely to do so with an unsafe tool.

My point exactly. Just like it isn't the fault of the straight razor
that you can't use it, it isn't C's fault that so many incompetent
"programmers" (I use that term very loosely!) use it to write bad
programs.

>
>> I don't know how to break this too you, but C doesn't have a "string"
>> datatype. There is nothing to prevent anyone from doing strings any
>> way they please (like, for instance, the UCSD Pascal way).
>
> They are not prevented from doing differently, but they are certainly
> *encouraged* by the fact that so many of the CRTL (and Unix system calls)
> pass string arguments this way.

Thus my original comment about inertia.

> And, I know C doesn't have a "string" type
> but it does pass what people think of as strings as an address of an array,
> the end of which is only known when a null byte is encountered. Perhaps if
> it had defined a proper string type like Fortran and Basic,

Well, I haven't used Fortran since F77, but base don that your now
batting about .330. While some BASICs did have string types (but not
all BASICs) Fortran, at least as far as F77 did not. It used, are
you ready for this, CHARACTER arrays, just like C, except they probably
would not have been null terminated.

> which allowed
> the compiler writers to implement pass by descriptor we wouldn't have seen
> so many occurrences of this type of bug.

I would have to look, but I am not sure either the BASICs I worked with
or the Fortrans I worked with used "pass by descriptor". I think that
was originally a DEC thing which may have then leaked into the rest of
the world.

>
>> Ye, and long after all this was known newer versions of sendmail
>> continued to have this problem. The reason was apathy and not the
>> C programming language. How long ago was the weakness in "null
>> terminated strings" revealed? Why do we still have them? Not
>> because of C, but because programmers don't really care. And,
>> apparently neither do their bosses.
>
> But if a language that did have a string passing mechanism such as
> descriptors was used in the first place,

Hindsight is always 20-20. Sendmail was developed from a program called
"delivermail", written by Eric Allman back around 1979 on BSD 4.0. Now,
what do you think his choices were for a language in that environment
that would be protable to other sites running that environment? How
many 1979 BSD 4.0 systems do you think had any compiler other than the C
compiler that came with them?

> we wouldn't have had so many bugs
> to begin with. Your argument seems to be on the lines of "yes, it's
> dangerous, but everyone should know about it, and it's their fault if they
> do things the way the compiler and RTL encouraged them".

We were a rather naive industry in those days. You probably don't remember
the days of the early ARPAnet when MIT ran machines with people first names
as userids and no passwords because just like people wouldn't think of
invading your home computer system citizens wouldn't think of invading
your account. No one assumed that the time would come when every little
geek in the world would be spending his time breaking into, compromising
or crashing whatever system they can reach.

>
>> And, as I said, C doesn't have a string data type so why are these
>> problems still around? Programmer apathy, supervisor apathy and
>> acceptance of bad programming practice.
>
> On the part of the compiler designers certainly.

If the language doesn't have a string data type, how is the compiler
writer supposed to fix it?

>
>> I can (and have for demonstration
>> purposes) write bad programs in COBOL, Pascal, Ada, Java, Fortran.
>> Algol, PL/I, etc. etc. etc. No langauge can stop a prgrammer from being
>> stupid.
>
> But a sensibly designed language should not actually encourage dangerous
> practice.

C doesn't encourage or discourage anything. It is totally neutral. Like
I said, I can write some really bad stuff in COBOL. (I've been on the
maintenance end of some of this really bad code!) It's not COBOL's
fault.

> One can be a dangerous lunatic on the road with any type of car,
> but that doesn't mean car safety design is a waste of time. It's about
> reducing the likelihood and limiting the scope of stupidity, not preventing
> it altogether.

So then, why don't we all drive totally indestructable vehicles like
tanks? Because it is not practical to try to exhibit that much control
over people's actions. I would really rather not have to program with
my hands tied behind my back. I can always type with my nose, but it
will definitely decrease my productivity.

bill 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

Relevant Pages

  • Re: Help from fellow Fortran Users
    ... >> department head winced and commented that Fortran is no longer being ... Portability, for programs written in any language, depends on four ... A compiler that generates code for an AXP platform is not ... Some programmers are just so impressed with their own knowledge of the ...
    (comp.lang.fortran)
  • Re: A question on Newtons Method
    ... >> I can't believe you'd advise a noob to use a compiler which is still ... > production codes and codes from textbooks. ... > The Fortran standard generally does not specify the required behavior ... >> another important class of hassle which most numerical programmers ...
    (sci.math.num-analysis)
  • Re: Numbers and truth values
    ... only say I'm happy I stopped using Fortran heavily before such standards ... illegal to change a constant and the compiler is still not required to ... such code as before, helping programmers spot errors. ...
    (comp.lang.python)
  • Re: How calling a cpp-dll?
    ... | In cpp the string is correct, but the string in Fortran is empty. ... You should tell the compiler that StdVar_String uses whatever calling ...
    (comp.lang.fortran)
  • Re: Fortran or C
    ... > I take it you mean that the compiler checks for these semantic errors in ... Fortran 95 with a good ISO_VARYING_STRING library implementation. ... C++ with a good standard string library and lots of bounds checking ...
    (comp.lang.fortran)