[comp.lang.c] C Community's Cavalier Attitude On Software Reliability

wtwolfe@hubcap.clemson.edu (Bill Wolfe) (02/26/90)

 Following are some prime examples of why the C community is thought 
 of by many as having an unprofessional and irresponsible attitude 
 toward software reliability:
  
   DAB(!1)  There is a mysterious bug causing occasional core dumps...
            ...just send mail to the author.

   FILE(1)  It often makes mistakes.

   JOBS(3J)  There is no excuse for the "getwd" routine to be in the
             jobs library.  There is even less reason for this routine
             not to have been documented by the author(s) at Berkeley.

   PARSEDATE(3)  The grammar is incomplete and always will be.

   PUTC(3)  Errors can occur long after the call to 'putc'.

   SCANF(3S)  The success of literal matches and suppressed
              assignments is not directly determinable.

   SIN(3M)  The value of 'tan' for arguments greater than about 2**31
            is garbage.

   CTAGS(1)  ...if you have two Pascal procedures in different blocks
             with the same name, you lose.

   EMACS(1)  Not bloody likely.

   TC(1)    The aspect ratio option is unbelievable.

   UNITS(1)  Don't base your financial plans on the currency conversions.

   BBEMACS(1)  I tinker too much, so occasionally I mess up and it
               don't work no good.  But then I fix it, hooray.

 When examples such as these are combined with the existence of so many
 blatantly unsafe constructs within the C language, and the fact that C
 software seems to erode public confidence in software reliability on a
 regular basis (Nationwide Computer Network Infected By Worm; National 
 Telecommunications System Crashes), it would seem appropriate to ask:

   When is the C community going to clean up its act???

 It appears that there is a real need to publicize software engineering 
 concepts throughout the C community, both directly through software
 engineering education and indirectly through a redesign of the C language
 to provide greater support for the software engineering process.  If
 these steps are taken, it will hopefully be possible to avoid any further
 destruction of the public's confidence in software reliability.  If not,
 government regulation of the field will probably soon become inevitable.


 Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

john@newave.UUCP (John A. Weeks III) (02/26/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:

> [ ... List of bugs in software that Mr Wolfe is probably using for FREE ]

Bill,

I take great exception to your accusing me of being unprofessional.

I can write really good or really bad code equally well.  The difference
between the two is the amount of time that I am allowed, and how much
I am being paid. 

> When examples such as these are combined with the existence of so many
> blatantly unsafe constructs within the C language, and the fact that C

            ^^^^^^ read "useful"

> software seems to erode public confidence in software reliability on a
> regular basis (Nationwide Computer Network Infected By Worm; National 
> Telecommunications System Crashes), ...

Would you feel better if the networking code was written in BASIC?
I bet someone would have to modify BASIC to allow exponential format 
for the line numbers.  Didn't Church prove that you can develop an
equally poor implementation of a problem in any language?

>                                ... it would seem appropriate to ask:
>   When is the C community going to clean up its act???

The big issue is economics.  You can have the current nationwide
network for X dollars, or a "totally secure" network for many times
more than X.  Please think about three facts:

	1. Totally secure is not possible (nor is totally reliable)

	2. Extra levels of security will probably reduce overall
	productivity at all levels, so you can multiply X a few
	more times.

	3. If the cost were much higher, would it exist at all?

If my managers doubled our development budget, we might improve
the quality of our already excellent products.  But more likely,
management would rather have us turn out twice as many products.

> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education ...

The solution to an economic problem is an economic solution: pay good
programmers well, pay poor programmers poorly.  As long as poor
programmers are in heavy demand, poor code is going to be written.
The economics will dictate the accepted level of education (my theory
on why MBA's are so popular).

If you wish to construct a top-notch product, hire top-notch programmers
with a proven track record, and pay them well.  If you hire an overworked
grad student for $3.65 an hour, you may find that your employee might not
really care about doing a good job.

>                   ... and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.

Isn't one version of ADA enough?

> If not, government regulation of the field will probably soon become
> inevitable.

Yea, right.  Like government regulations keep seedy people out of the 
legal profession.  And MD's never let drinking problems affect their work.

I used to work in an industry that required all workers to have federal
permits.  There were some very good and some very poor radio technicians,
but most were in the average category.  Now that the FCC no longer 
requires federal permits for radio workers (only for radar and for federally
regulated installations...like air traffic control), the industry still
has the same mix of people.  Some good, some bad, but most are average.

The bottom line?  If you have a problem with a program, do not blame
the programmer.  Aim the questions at his or her management.  Management
is ultimatly responsible for all software projects, whether it be a
Microsoft sized company or a professor with 1 part-time student worker.

(I exempt the wonderful software that is posted by USENET people from
this discussion and from my "bottom line".  Freeware is in a class
above this discussion.)

-john-

-- 
===============================================================================
John A. Weeks III               (612) 942-6969               john@newave.mn.org
NeWave Communications                ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================

ok@goanna.oz.au (Richard O'keefe) (02/26/90)

I'm fond of saying "the more I like C, the better I like Ada",
but I really couldn't let Bill Wolfe's message pass unchallenged.

In article <8147@hubcap.clemson.edu>, wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>  Following are some prime examples of why the C community is thought 
>  of by many as having an unprofessional and irresponsible attitude 
>  toward software reliability:

>    DAB(!1)  There is a mysterious bug causing occasional core dumps...
>             ...just send mail to the author.

What is dab?  How do you know it is written in C?

>    FILE(1)  It often makes mistakes.

'file' is a UNIX command which tries to guess what kind of information
a file contains.  The UNIX file system does not have store 'type'
information with files, so it CAN only guess.  (One file system I have
used tagged files as PascalSymbol, AplWorkSpace, AlgolCode, and so on,
for over 200 different types.  The Macintosh file system does much the
same.  Unix _doesn't_.)  Current versions of 'file' are controlled by
an /etc/magic file, but you can't tell them about new programming
languages (if anyone has a version of 'file' which looks for keywords
in /usr/lib/vgrindefs, let me know).  But the classification task is
in principle impossible to get precisely right:  is
	(+ 1 1)
(a) Lisp, (b) Scheme, (c) data for a Lisp or Scheme program,
(d) something else?

This has _nothing_ to do with the language that 'file' is written in.

>    JOBS(3J)  There is no excuse for the "getwd" routine to be in the
>              jobs library.  There is even less reason for this routine
>              not to have been documented by the author(s) at Berkeley.

That was a temporary hack in 4.1BSD.  There is no jobs library in 4.2BSD
or 4.3BSD and getwd() _is_ documented.  Again, where is the evidence that
this has something to do with C?  (I've seen one OS written in Pascal and
another in Fortran, and have _no_ reason to think them better.)

>    PARSEDATE(3)  The grammar is incomplete and always will be.

This is another problem which is unsolvable in principle.  What is
provided is a useful approximation.  The incompleteness has nothing
to do with C as such.  (The fact that parsedate was distributed free
over the net _does_ have something to do with C.)

>    PUTC(3)  Errors can occur long after the call to 'putc'.

This _is_ a property of the programming language C, now that the
stdio library is a standardised part of the language.  There are
two parts to the problem:
    -- most implementations of putc() don't check that the file is
       in output mode at the time of call; _that_ I cannot excuse
       because it is easy to implement stdio so that it _does_
       check then and there (the trick is to use *two* counters:
       "how much input left in buffer" and "how much space left
       for output in buffer").
    -- even if the file is in output mode, _physical_ I/O errors
       are not reported immediately.

It is worth noting that the second point ALSO applies to UNIX
implementations of Ada.  It must, because it is a UNIX problem, not
a C problem.  In fact, because of the way UNIX buffers disc i/o,
a physical error may not be detected until after the file is CLOSED,
which is a right pain.  Some recent UNIX systems do provide a system
call which can be used to prevent the problem; I am told that it is
costly.  I imagine that this problem does not occur under MS-DOS.

>    SCANF(3S)  The success of literal matches and suppressed
>               assignments is not directly determinable.

Scanf() is one of my pet hates.  It is surprisingly slow as well.

>    SIN(3M)  The value of 'tan' for arguments greater than about 2**31
>             is garbage.

I am indebted to Bill Wolfe for pointing this one out; I usually go by
the SVID (which is quite explicit that for partial loss of significance
as much as possible of the result must be returned and that for total
loss of significance a message is printed and 0 returned; in either case
errno is set to ERANGE), or by a draft of the ANSI C standard (which
does not license anything like this), or by SunOS documentation.
The Encore manual page does contain this message, which apparently pertains 
to some 4.2BSD implementations, and it had never occurred to me that it
might.

It's worth pointing out that there is nothing in Ada to prohibit an
Ada implementation doing this too:  tan() is _not_ an official part
of Ada.  It would be worth checking what Ada systems do on 4.2BSD...

Yes, I know about the Ada Numerics Working Group.  I am really
enthusiastic about their definition of the trig functions, and that
definitely really does give you something you can _trust_.  I would
be _very_ happy for that to be cited in an appendix to the C
rationale as a worthy guide for C implementors (too late to affect
the standard).

By the way, is the version of tan() in question written in C, or is
it written in assembler?  It makes a difference to the argument!

>    CTAGS(1)  ...if you have two Pascal procedures in different blocks
>              with the same name, you lose.

The whole idea behind a 'tags' file is that there is only one occurrence
of any given name as a routine name in the given cluster of files.  This
specific problem is not a problem with 'ctags' as such, but a consequence
of the fact that the data structure it is required to construct simply
cannot express this situation.

There _are_ serious problems with ctags.  In particular, because it
operates on the raw text instead of preprocessing and parsing it, the
following example
	#if 0
	#define foo(x,y) (((x)+(y))/2)
	#else
	double foo(x, y)
	...
	#endif
will be misunderstood:  the first occurrence of 'foo' will be mistaken for
the definition and the real definition will be reported as an error.

Another problem is that 'ctags' and 'file' use different heuristics for
guessing the language of a file.

The fundamental problem is that 'ctags' is trying to do something which
is not in principle doable, thanks to the existence of the preprocessor.

>    EMACS(1)  Not bloody likely.

This tells us nothing about C.  (Particularly when you consider that
Emacs variants have been written in Teco, Lisp, PL/I, Pop, and C, to
name but a few.)

>    TC(1)    The aspect ratio option is unbelievable.

What _is_ tc?  We haven't it here, and it's not in the SVID.
How do you know it is in C?

>    UNITS(1)  Don't base your financial plans on the currency conversions.

This has nothing to do with C.  It's a straightforward consequence of the
fact that the 'money' part of /usr/lib/units was fixed at 16-June-1980.
The currency conversions are just fine for that day.  Since the 'units'
program is driven by a readable source file, if you want current figures,
plug 'em in.

The issue here is not a LANGUAGE issue but a DESIGN issue.
Shall we
a) not provide any currency conversion information at all?
b) provide currency conversion correct at a particular date,
   but with no _automatic_ means of updating it?
c) provide currency conversion updated daily?  From what source?

Exactly the same choices would confront an Ada user, and exactly
the same considerations (how can we get at currency figures _portably_)
might lead to the same choice.

(Since the introduction of the 'news' software; it would make sense to
have a comp.currency newsgroup with daily updates...)

>    BBEMACS(1)  I tinker too much, so occasionally I mess up and it
>                don't work no good.  But then I fix it, hooray.

This is pretty shocking, but what has it got to do with C?

The very *worst* publicly available software I have ever seen was
written in Pascal.

>    When is the C community going to clean up its act???

What C community?  Wolfe cited some utilities & libraries from 4.2BSD,
does he mean Berkeley?  He cited some programs I've never heard of
(dab, tc, bbemacs), does he mean their authors?  He cited some functions
from the C library, most of which HAVE been cleaned up.

The really important thing is that Wolfe has failed to show (and didn't
even _try_ to show) that there was any causal connection between the
defects of these programs and the use of C.  Remember Sturgeon's Law:

	90% of _everything_ is crud.

I repeat, the more I use C, the better I like Ada.  (And Eiffel.)
(No, _especially_ Eiffel.)  But Wolfe needs a better argument.

>  It appears that there is a real need to publicize software engineering 
>  concepts throughout the C community, both directly through software
>  engineering education

I agree 100% with this, except that I'm not convinced that there IS a
single "C community" whose act needs to be cleaned up.

What we really want is a large number of low-cost (< US$300, say)
Ada compilers scattered around enough so that people start contributing
Ada sources to the net.  Then we'll get a chance to see how much of a
difference the language makes.  In the mean time, we have to make do
with what we've got.

dmr@alice.UUCP (Dennis Ritchie) (02/26/90)

Wolfe, I gather, intends to construct a case against C by grepping
for titillating phrases in the BUGS section of his manual.

Rather than decry the C community's derelictions in not maintaining
a direct line to the international money markets (so as to keep
the monetary conversion coefficients of the units program
up to date, and thereby salvage our reputation in the software
engineering biz), I think it would be more appropriate to discuss
Wolfe's (wtwolfe@hubcap.clemson.edu) complicity in recent
and past Clemson football scandals.  Did he have any role
in the jock dormitory affair?  What was his relationship with
Danny Ford?

These questions seem approximately as relevant as the ones Wolfe
raises.

	Dennis

btrue@emdeng.Dayton.NCR.COM (Barry.True) (02/26/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>
> [ Comments about certain commands in C and their 'pitfalls' deleted]
>
> When examples such as these are combined with the existence of so many
> blatantly unsafe constructs within the C language, and the fact that C
  ^^^^^^^^^^^^^^^^
> software seems to erode public confidence in software reliability on a
> regular basis (Nationwide Computer Network Infected By Worm; National 
> Telecommunications System Crashes), it would seem appropriate to ask:
>
>   When is the C community going to clean up its act???
>

Blatantly unsafe???? How doe you define BLATANTLY? And unsafe for whom? The
inexperienced C programmer? I would hazard to guess that there are many
constructs in many languages that would be confusiong to an inexperienced
programmer of that language until they learned to use them properly. These
constructs could be termed unsafe to use by that programmer until he/she
learned enough about the language to know in what context they could be use
"safely" and efficiently. To labal a construct as blatantly unsafe,
however, is to say that that construct is unsafe for use by ALL programmers
in ANY environment and in ANY usage WHATSOEVER. I think that this is a bit
much to say for any programming language construct.

> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  If
> these steps are taken, it will hopefully be possible to avoid any further
> destruction of the public's confidence in software reliability.  If not,
> government regulation of the field will probably soon become inevitable.
>
You don't redesign the language to teach a programmer how to use it. You
have to develop better methods in training a programmer in the proper use
of the language. To single out the C community (or any other programming
community) as needing to adhere to better software engineering concepts in
exclusion of any other programming community is hogwash. I have been
programming in C/UNIX for ten years. In that time I have seen my share of
bad programming practices, none the least of which was poor quality
training. I have worked in shops where the impression of C was that any
competent programmer could learn how to use it effectively by taking a
one-week class. This was a COBOL/CICS shop, by the way. It appears from
this that it is not the C community that needs to developm better software
engineering concepts, it is the software community in general. Show me a
COBOL programmer that can learn enough about all implementations of C in
one week to be able to "safely" and efficiently program in the language in
EVERY circumstance and I will personally doff my hat to the next generation
of super-programmer..8-)!!!

jharkins@sagpd1.UUCP (Jim Harkins) (02/27/90)

So out of several thousands of commands and programs, some quite complex
(like emacs) you found a handful of bug reports and use this to condem C?
It seems to me like you are stumbling over one of the philosophical questions
of programming, to wit: If there is a known bug to you tell the customers
about it or hope they never see it?  If you tell them about the bug then they
may get cold pricklies about your software, but then again they may admire
your forthrightness, especially if you can prevent them from losing hours of
work by tripping over the bug for themselves.  If you don't tell them about
the bug (this seems to be the way 90% of companies operate) then chances are
most people won't stumble over all the bugs so they won't know how bad the
software really is.

And don't tell me that software shouldn't be shipped without bugs, this is
the real world.

-- 
jim		jharkins@sagpd1

"I've found by and large that when the flu gets you, the best thing to do (other
 than go to bed, which is boring) is to go conquer something." -Jerry Pournelle

jacob@gore.com (Jacob Gore) (02/27/90)

/ comp.lang.c / wtwolfe@hubcap.clemson.edu (Bill Wolfe) / Feb 25, 1990 /
>  When examples such as these are combined with the existence of so many
>  blatantly unsafe constructs within the C language, and the fact that C
>  software seems to erode public confidence in software reliability on a
>  regular basis (Nationwide Computer Network Infected By Worm; National 
>  Telecommunications System Crashes), it would seem appropriate to ask:
>
>    When is the C community going to clean up its act???

Which public is that?  The same public that absorbed the TV coverage of the
Hackers' Convention as a gathering of high-tech revolutionaries?

>    Nationwide Computer Network Infected By Worm

Robert Morris's Internet Worm?  Only one of the three holes it used had
anything to do with C, the other two were exploiting human laziness.  Or
are you talking about the more recent DECnet worm?

> National Telecommunications System Crashes

I'm not sure what you're talking about here.  If you are referring to the
recent near-meltdown of AT&T's long distance phone network, I don't think
AT&T's phone switch software is written in C (I believe it's some
assembly-level language).

Look, I am as much for reliable software as the next guy, but don't go
around setting up straw programs to beat up.  As for the BUGS section in
Unix manuals, sure they surprise people, until they realize that a
documented known bug, which may not be fixed for a variety of reasons, is
much easier to deal with than a bug swept under the rug and not fixed for
those same reasons.

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

henry@utzoo.uucp (Henry Spencer) (02/27/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:

Bill, aren't you confusing C with Unix?  Some of the software you mention
is not even written in C on most Unixes.  Actually, I think you're
confusing C with the Unix from your particular vendor, since some of
the programs you mention are things I've never heard of that don't
appear in any of the quasi-standard sources.

>   FILE(1)  It often makes mistakes.

Necessarily so; there is no way to be certain of the type of a file in
an operating system which doesn't tag files with types, so file(1) has
to guess.  This is documented.

>   PUTC(3)  Errors can occur long after the call to 'putc'.

This is a problem with any buffered i/o package in any language/system.
Delaying i/o in hopes of doing it in larger units inherently delays
reports of i/o errors.

>   SCANF(3S)  The success of literal matches and suppressed
>              assignments is not directly determinable.

Yup, a slightly bad design which is difficult to fix because of problems
of backward compatibility.  Scanf is, in any case, unsuited to heavy-duty
input parsing; it's strictly for quick-and-dirty lightweight stuff.

>   SIN(3M)  The value of 'tan' for arguments greater than about 2**31
>            is garbage.

Complain to your vendor -- this is an implementation problem on your
particular machine, although range reduction on trig functions is in
general a tricky problem.  As near as I can tell with a quick test,
the one here gets it right.  Note that the C standard forbids such
misbehavior; your vendor has blown it.  Long odds his Fortran TAN()
function is just as broken.

>   UNITS(1)  Don't base your financial plans on the currency conversions.

Almost any source of currency data which isn't on-line with world money
markets will carry the same warning... or should.  (Actually, this is a
more general point:  the things you point to are at least *documented*,
which is often not the case for bug lists in other systems.)

> When examples such as these are combined with the existence of so many
> blatantly unsafe constructs within the C language, and the fact that C
> software seems to erode public confidence in software reliability on a
> regular basis ...

In a way that Cobol and Fortran programs, not to mention assembler programs,
somehow don't?  If you read comp.risks, you will find that such problems
are by no means confined to C.  There are incompetent programmers using
just about every language you care to name.

> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  If
> these steps are taken, it will hopefully be possible to avoid any further
> destruction of the public's confidence in software reliability.  If not,
> government regulation of the field will probably soon become inevitable.

The above paragraph, of course, is true with a global substitution of any
programming language -- Fortran, Cobol, assembler, Ada, you name it -- for
C, and merely reflects the gross incompetence of many people who claim to
be programmers.  "The most failure-prone part of your car is the nut behind
the wheel."
-- 
"The N in NFS stands for Not, |     Henry Spencer at U of Toronto Zoology
or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

peter@ficc.uu.net (Peter da Silva) (02/27/90)

If you want to talk about blatantly unsafe constructs, how about ADA's use of
rendezvous as the primary (maybe only) message passing construct? The MINIX
operating system is written in C, but the biggest source of subtle bugs in the
system (from my observation of the discussions in comp.lang.minix) is the use
of rendezvous. I understand that the DoD has given up on using ADA's tasking
and switched to a hosted environment on top of VRTX partly because of this.

Then again there's the use of operator overloading to sort-of-implement object
oriented programming. "So what does `A+B' mean in this context?"

I suspect that a major reason that C bugs and Fortran bugs and Cobol bugs are
better known than ADA bugs and PL/I bugs is simply because these languages have
seen more use. A new broom sweeps pretty clean...
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

martin@mwtech.UUCP (Martin Weitzel) (02/27/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>
> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:
>  
[list of citations deleted]

A language with no bugs documented does not necessarily have none.
A language that is not critized for deficiencies, is suspicious not
to be in wide use.

Two years ago I decided to start a project with INFORMIX 4GL.
From time to time my work went into isolating contained Bugs.
(Because I just was learning myself, it often took some time
to trim down the problem to the smallest failing case, then
to detect that it was not my fault and finally finding some
workaround.) Of course, the bugs were never mentioned in any
manuals and might give some naive user the impression, that
the language was "better" than C. I think within three months
of work I spent at least three weeks with isolating bugs and
looking for workarounds!

The next thing I missed in this language were constants:
You could not do other than writing them explicitly twice,
if you defined an array and had to write a loop to process the
entries later. I think, a language that calls itself "fourth
generation" should have learned from 3rd generation languages!
I had to circumvent this by writing my own preprocessor (with
UNIX m4). The support for structuring a program into multiple
reusable moduls, was far below that of C.

Language constructs seemed somewhat arbitrary defined.
Eg in C, if there is a 'int'-value required, there are
only two situations: It must be a compile-time expression
or it can any expression evaluated on run-time, ranging
from a constant to a complicated expression with indexed
array elements or whatever. Not so in 4GL: Sometimes a
constant and a variable was allowed, sometimes only
a constant or only a variable (yes, there were situations
were a *value* which was used unchanged had to be a
from a variable, not a constant.) Sometimes expressions
were allowed, but on other occasions theese should not
have any array-elements embedded. Again: this language
was called a *fourth* generation language.

Finally, the project was unsuccesfull on the 80286, because
of its limited (segmented) adress space and the tendency of
a 4GL-Program to grow really large in a serious programm, that
had to do a little more than the demo data base that came
with 4GL. I allways lived in the fear, that I could reach the
limits of some resource, because for the fewest of them any
"minimum guarantees" were given! Finally, the 80286 segmentation
and the linker came into way. (With C I could be sure, that
anything as complex as a compiler and the UNIX-Kernel can
be writte in this language.)
>
> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  If

A C programmer needs more education, training and knowledge as the
average BASIC programmer - but not because the language is worse
in design than others, but because more serious work is done in C.
I don't believe, that any other language with the same broad
spectrum of uses as C, can be designed to be used with less effort
or education. You may take this as my vote, that we need more
specialized languages for certain problem domains, but I think
there is few room for a 'better C'.

At least for INFORMIX 4GL (in the state of design from 1988) I can
say, that a newer language which promissed that you "describe the
solution, not the way to get to the solution" was worse than C
in any aspect, if you tried to use it for non-trivial projects!
(BTW: ESQL/C is much better in this respect, but leads the not
so well educated programmers into all traps and pitfalls you find
in C.)

> these steps are taken, it will hopefully be possible to avoid any further
> destruction of the public's confidence in software reliability.  If not,
> government regulation of the field will probably soon become inevitable.

What kind of regulation are you thinking of? (Don't know,
if I should put a Smiley here or if you forgot one ....)
>
>
> Bill Wolfe, wtwolfe@hubcap.clemson.edu
> 
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

daw@cbnewsh.ATT.COM (David Wolverton) (02/28/90)

> In article <8147@hubcap.clemson.edu>, wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
> >    SIN(3M)  The value of 'tan' for arguments greater than about 2**31
> >             is garbage.

Seeing this reminded me to mention to the net that math libraries need
not be bad.  While it is probably true that even some recent UNIXes
contain some bad math functions, they need not.  Anyone who is responsible
for a C implementation should do at least as well as the 4.3 BSD libm,
which is very careful about things like loss of accuracy.
The math library in SVR4 uses the 4.3 libm, plus some additional
accuracy improvements (see the paper in the winter Usenix proceedings)
from various places.

Dave Wolverton
daw@attunix.att.com

karl@haddock.ima.isc.com (Karl Heuer) (02/28/90)

In article <1990Feb26.234321.1072@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>>   SCANF(3S)  The success of literal matches and suppressed
>>              assignments is not directly determinable.
>
>Yup, a slightly bad design which is difficult to fix ...

Since nobody else has said it yet, I will:

Fixed in ANSI C, via the "%n" directive.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (02/28/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>
> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:

The following comments, taken out of context, such as they are, prove
little.  And, when put back into context prove even less.  Your
comment about cavalier attitude to programming is not something that
is unique to C.  It should be pointed out that any of these programs
could have been written in Pascal, or Basic, or Assembler and still
have the same problems and/or manifestations.

If you are talking about the writing style of the comments you
present, as opposed to the actual content of the messages, then  you
are attacking a different thing: namely that the quality of most
manuals is awful.

To site a few contraditions  to your messages:

>   DAB(!1)  There is a mysterious bug causing occasional core dumps...
>            ...just send mail to the author.

Agreed, bad style, but some bugs are extremely hard to detect.  I am
not sure what DAB is so I can't comment on this more.


>   FILE(1)  It often makes mistakes.

This is not a programming issue, but rather a problem with being able
to deterministicly tell what any type of file is.  This is very
difficult if you do not have an attribute oriented filesystem since
source code will look like English text and Vice Versa.


>   JOBS(3J)  There is no excuse for the "getwd" routine to be in the
>             jobs library.  There is even less reason for this routine
>             not to have been documented by the author(s) at Berkeley.

The author of the manual page may have a point, but may not be able to
rectify the problem due to historical significance.  Better to point
it out so that future coders could rectify the problem given the
chance.

>   PARSEDATE(3)  The grammar is incomplete and always will be.

The grammar for dates is notoriously ambiguous.  Everybody has a
favorite way of writing "the twentieth day of the Fifth month of 1990".
Some say 5-20-90, some say 20-5-90, some say 90-20-5, some say
20-May-90, etc.  This is another one of those potentially
non-deterministic type things, primarily due to the fact that 2-5-90
can be interpretted in two different ways.

>   PUTC(3)  Errors can occur long after the call to 'putc'.

Not a problem of the implementation, but a function of the way that
Unix (and other systems) do file buffering.

>   SCANF(3S)  The success of literal matches and suppressed
>              assignments is not directly determinable.

If you know scanf, then you know that this is true.  Basically you ask
for the computer to pattern match something for you, but tell it not
to let you know what it matched, if anything.  Would be tough
(impossible?) to fix given the current interface.

>   CTAGS(1)  ...if you have two Pascal procedures in different blocks
>             with the same name, you lose.

If you build a single key data base with two identical keys and then
attempt to access the database using that key...

>   EMACS(1)  Not bloody likely.

Huh?

>   TC(1)    The aspect ratio option is unbelievable.
>
>   UNITS(1)  Don't base your financial plans on the currency conversions.

Currency conversions in Units are meant to be rough gueses.  Since
units can't go query the NYSE to get the current rates, what do you
want it to do?

>   BBEMACS(1)  I tinker too much, so occasionally I mess up and it
>               don't work no good.  But then I fix it, hooray.

Sounds like and honest programmer.

> When examples such as these are combined with the existence of so many
> blatantly unsafe constructs within the C language, and the fact that C
> software seems to erode public confidence in software reliability on a
> regular basis (Nationwide Computer Network Infected By Worm; National 
> Telecommunications System Crashes), it would seem appropriate to
ask:

Worms and viruses and hackers and system crashes and unreliable
software and poor programming and bad software design and, and, and,
all existed long before C was even invented and will persist thoughout
time.  Again, I would like to point out that the Worm could have been
written in Assembly, Pascal, etc.  

C software does nothing to erode public confidence.  Poorly crafted
software erodes public confidence.  There are some pretty attrocious
programs in ADA, PASCAL, MODULA-2.  You know, all those languages that
are not supposed to allow you to write bad code.  Sorry, but they all
have bugs too.

>   When is the C community going to clean up its act???

When are the Cobol programmers of the world going to stop bashing on C
and start writing the banking software correctly so that I don't get
notices from the bank saying that I am roughly 1.5 Million dollars
overdrawn?  When are they going to fix code so that programs don't
abend causing 4.5 Million dollars to be misplaced?  Both of these
things happend.  One to me (the first), the other I helped track down
at the Federal Reserve Bank.  Golly, maybe Programmers make the errors
not the programming language.  You think?  Nah...

>> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  If
> these steps are taken, it will hopefully be possible to avoid any further
> destruction of the public's confidence in software reliability.  If not,
> government regulation of the field will probably soon become
> inevitable.

Sorry pal.  Start by teaching all those cobol hacks to quit sending
letters demanding payment of $0.00 dollars, and make sure that the
design of assembly language, lisp and fortran are also all added to
the list of languages which need to be redesigned to provide greater
support of the software engineering process.  Then make common tools
to support such effort for all the languages, rather then the 35,000
or so tools that exist today, some of which are a lot more buggy that
the phone system ever was...

Then force all code to be mathematically tested for accuracy.  But
tell you what, since all of the rest of us programmers obvously can't
write software worth a damn, you better start working on this stuff
right away: you got a lot of code to write...
-- 
Mark H. Colburn                     If you don't make money off of it,
Open Systems Architects, Inc.	    it had better be either a religious
mark@Minnetech.MN.ORG		    experience or a hobby. 
							- Lance Cooper

ok@goanna.oz.au (Richard O'keefe) (02/28/90)

Bill Wolfe wrote:
: SCANF(3S) The success of literal matches and suppressed
:           assignments is not directly determinable.

Henry Spencer wrote:
: Yup, a slightly bad design which is difficult to fix ...

In article <16046@haddock.ima.isc.com>,\
karl@haddock.ima.isc.com (Karl Heuer) wrote:

: Since nobody else has said it yet, I will:
: Fixed in ANSI C, via the "%n" directive.

Nobody else said it, because it isn't true.  The explicit complaint is
that "the success of literal matches and suppressed assignments is not
directly determinable".  As an example of this, suppose I do
	result = scanf("%*d%*d%*d");
Now scanf() is defined (in one manual I have) to return "the number
of input items matched and assigned, or EOF if the function does not
store values before it sets the end-of-file or error indicator for
the stream".  In this particular case, that means that precisely two
outcomes are possible:  0 and EOF.  It is not possible to tell how
many of the %*d conversion specifiers matched something.

The new %n conversion specifier tells us how many _characters_ have
been processed.  We _can_ use it to count the matches.  Here's how:

	int p1, p2, p3, result;

	p1 = p2 = p3 = -1;	/* any negative value will do */
	result = scanf("%*d%n%*d%n%*d%n", &p1, &p2, &p3);
	if (p3 >= 0) { all three %*d items matched } else
	if (p2 >= 0) { first two %*d items matched } else
	if (p1 >= 0) { only first %*d item matched } else
	             {        no %*d items matched }

It is a great improvement that this is possible, but it really doesn't
count as "DIRECTLY determinable".

One very simple change would have done:  _add_ a new suppression
character, say "#".  %#<fmt> would act exactly like %*<fmt> except
that it would be counted.  Then the desired effect could be achieved:
	result = scanf("%#d%#d%#d");
This is all that is needed:  the construct %#0c would read no
characters and would not store them anywhere, but it _would_ increment
the counter.  So to check for the dreaded message,
	result = scanf("Hello%#0c world#0c");
would set result to 2 if the whole of "Hello world" was matched.

Presumably the ANSI C committee considered and rejected some such
proposal.  It would be intersting to know why (no prior art, perhaps).

It doesn't bother me, because I find that using my own "parsing" functions
and the standard conversion functions (strtol, strtod, strtoul) is 
    - easier for C to check (no varargs functions)
    - easier for C to optimise (no pointers needed)
    - more flexible (e.g. I can allow "#..\n" comments)
    - as portable as getc()
    - and *still* 20% or more faster than typical UNIX implementations
      of scanf().
Just because something is in the standard doesn't mean you _have_ to
use it.

shurr@cbnews.ATT.COM (Larry A. Shurr) (02/28/90)

In article <10529@alice.UUCP> dmr@alice.UUCP (Dennis Ritchie) writes:
>Wolfe, I gather, intends to construct a case against C by grepping
>for titillating phrases in the BUGS section of his manual.

Hmmm... Perhaps Wolfe is right, the C community (whatever that is) should
clean up its act.  Let's clean up those manuals by removing those pesky
"BUGS" sections and rewrite them, liberally using phrases such as "error-
free," "advanced software engineering features," and the like.

Yeh.  That's the ticket.  If only the C community would clean up its act,
then there would be no more problems.  The world's ills are caused by C
programmers.  After all, everyone knows that the No. 7 signalling network
would not have failed on M.L.K. day if the software had been written in
(pick one) Pascal, Modula-2, Eiffel, etc...

regards, Larry

Hi Randy!
-- 
Signed: Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las)
Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave
(With apologies to the real thing.  The above represents my views only.)
(You may now R'eply.  Forwarding from cbnews to my mail address now works!!!)

tneff@bfmny0.UU.NET (Tom Neff) (02/28/90)

I think what Bill Wolfe is getting at is this: C and UNIX derive from a
milieu where admitting fallibility is not a sin because the "consumers"
are programmers, whose competence, understanding and goodwill are
assumed; and where explaining bugs up front is considered a plus,
because it saves programmer time later on.

By contrast, "big computer company" tradition emphasizes the *appearance*
of infallibility -- never admit bugs up front because your competition
will eat your lunch.  Instead, pour money into glossy docs that paint
your product as the ultimate in completeness and perfection, *regardless*
of what a bug-filled mess it really is.  Handle the messy end only after
the check clears. :-)

What he appears to be saying is that if C and UNIX want to beat IBM at
its own game, to win in the marketplace despite programmer curses and
muttering, they will have to drop the embarrassing candor and get a
haircut.

This might even be true except the horse is out of the barn.  C and UNIX
have *already* been adopted by all the big computer companies, who are
diligently working to produce infallible-sounding derivatives with
gleaming three-color docs.  So who's left?  Has Bill been reading the
Berkeley manuals and wishing they'd go corporate too?  Dream on; they
have no motivation.

aperez@cvbnet.UUCP (Arturo Perez x6739) (03/01/90)

From article <8147@hubcap.clemson.edu>, by wtwolfe@hubcap.clemson.edu (Bill Wolfe):
> 
>  Following are some prime examples of why the C community is thought 
>  of by many as having an unprofessional and irresponsible attitude 
>  toward software reliability:
>   
	.... examples deleted ....
> 
>  When examples such as these are combined with the existence of so many
>  blatantly unsafe constructs within the C language, and the fact that C
>  software seems to erode public confidence in software reliability on a
>  regular basis (Nationwide Computer Network Infected By Worm; National 
>  Telecommunications System Crashes), it would seem appropriate to ask:

I'm frankly offended by the attitude displayed here.  I admit that C is
not the safest language to code in; it is, after all, just an abstract
kind of assembly language.  But if you don't like it, don't use it.  There
are "safer" languages to use, e.g. lisp, pascal, cobol.

But what offends me are these assumptions that
	1) C is responsible for the bad reputation software has.
	2) We need a C gestapo to enforce good coding practice.
	3) You can indict the whole C user community because of
	   a few "unreliable" applications.

All of the above assumptions are false.

Software has a bad reputation stemming from the days when IBM was writing
the OS for the 360, sometime in the 1960's.  And it hasn't gotten any better
with Companies (not Individuals) who make rash announcements of their products
and fail to deliver; usually due to unspecified "software problems."  Not all
of these companies use C; I doubt that the majority do.  I know that many
engineering companies still use Fortran.

Who is going to be the Gestapo?  I personally don't know anyone who would
want the job or be any good at it.

And, finally, since when can you indict a whole community based on the actions
of a few individuals?  Sounds like an "ism" to me.  What's the ratio of 
"well written" applications to "poorly written" applications?  If it's not
damn close to 0% then I think you're way offbase.

> 
>    When is the C community going to clean up its act???

When are "software engineers" going to clean up their acts?  I have on my
wall a list of excuses for DELIVERING poorly written, inadequately debugged
applications.  Why does these applications get released?  Because MANAGERS
decide what the deadlines are with little input from the engineers and
release the software based on criteria other than engineering considerations.
The number one reason (in my experience) for "bad" software is lack of time
and that lack of time is imposed from above.  There are only so many 70 hour
weeks you can put in.

> 
>  It appears that there is a real need to publicize software engineering 
>  concepts throughout the C community, both directly through software
>  engineering education and indirectly through a redesign of the C language
>  to provide greater support for the software engineering process.  If
>  these steps are taken, it will hopefully be possible to avoid any further
>  destruction of the public's confidence in software reliability.  If not,
>  government regulation of the field will probably soon become inevitable.

I don't believe that your efforts at education should be limited to "people
who write in C."  The problem you've very poorly addressed here is much more
pandemic than just being "people who write in C."

> 
> 
>  Bill Wolfe, wtwolfe@hubcap.clemson.edu
>  
Arturo Perez
ComputerVision, a division of Prime
aperez@cvbnet.prime.com
Too much information, like a bullet through my brain -- The Police

karl@haddock.ima.isc.com (Karl Heuer) (03/01/90)

In article <2922@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes:
>karl@haddock.ima.isc.com (Karl Heuer) wrote:
>>Fixed in ANSI C, via the "%n" directive.
>
>It is a great improvement that this is possible, but it really doesn't
>count as "DIRECTLY determinable".

A quibble.

>One very simple change would have done:  _add_ a new suppression
>character, say "#".  %#<fmt> would act exactly like %*<fmt> except
>that it would be counted.

My own idea was to add a new format *specifier*, say "%;", whose whole purpose
would be to increment the return value.  This is a conceptually simpler
change, and is equally powerful (your "%#d" is my "%*d%;", and you don't need
to play around with zero-width fields if the increment is all you want).  Note
also that the typical use would be to put a single "%;" at the end of the
format, to verify that the whole thing worked (which can also be done with
"%n"); normally one doesn't care about partial success.

>Presumably the ANSI C committee considered and rejected some such proposal.

I believe it was generally recognized that scanf() is a crock which continues
to exist only for backward compatibility.

>It doesn't bother me, because [it's usually better not to use scanf anyway]

Agree.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

martin@mwtech.UUCP (Martin Weitzel) (03/01/90)

In article <15213@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
>I think what Bill Wolfe is getting at is this: C and UNIX derive from a
>milieu where admitting fallibility is not a sin because the "consumers"
>are programmers, whose competence, understanding and goodwill are
>assumed; and where explaining bugs up front is considered a plus,
>because it saves programmer time later on.
>
>By contrast, "big computer company" tradition emphasizes the *appearance*
>of infallibility -- never admit bugs up front because your competition
[rest deleted]

I'll tell an anecdote on this: One big german company (Siemens), which
steped into the UNIX business around 1984, had to offer unix courses
for their customers. A true unix guru wrote some kind of textbook for
the courses. It started with the two pages "advantages of unix" and
"disadvantages of unix".

The latter was canceled by the sales departement, because
"a Siemens product has no disadvantages".
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

tanner@cdis-1.UUCP (Dr. T. Andrews) (03/01/90)

)  Following are ... prime examples of why the C community is thought 
)  of by many as having an unprofessional and irresponsible attitude 
)  toward software reliability: [ examples of "bugs" from "man" pages ]
On the other hand, I see this practice as commendable honesty.
Programs have bugs.  You know that, I know that, Mr. Wolfe knows
that.

Some of the things cited aren't amenable to change: do you really
expect the currency conversion tables for units(1) to update
themselves every morning from the currency tables in the paper?

That people will
	(a) admit that there are bugs,
	(b) identify them
	(c) solicit assistance in tracking them down
seems to me to be an example of an attitude toward reliability which
should spread.  Compare this to the attitude of the shrink-wrap folks
who say "works great.  no warranty once we receive the money."  When
was the last time your compiler vendor told you, up front, of the
things which don't work?  (On the other hand, report it and it may
turn out that it's a "known bug".)  Compare to the latest release
of PC-Word-Mung.

That authors of routines in xxx(3) admit that their routines do
not work in some silly cases (eg: tan(2**31)) also seems commendable.
You are warned to ask sensible questions of the routine.  By supplying
this information, the authors enhance software reliability in their
client programs.
-- 
{gatech!uflorida}!ki4pv!cdis-1!tanner {bpa uunet}!cdin-1!cdis-1!tanner

evil@arcturus.UUCP (Wade Guthrie) (03/02/90)

wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:

> Following are some prime examples of why the C community is thought 
> of by many as having an unprofessional and irresponsible attitude 
> toward software reliability:
  
> DAB(!1) [...] FILE(1) [...] JOBS(3J) [...] PARSEDATE(3) [...] 
> CTAGS(1) [...] EMACS(1) [...] TC(1) [...] UNITS(1) [...] BBEMACS(1)

#define FLAME TRUE

What do THESE have to do with the C community?  I can tell you that
I feel myself a member of that community and have NEVER programmed
one of these.  

Moreover, one can put things in "local language" without being 
irresponsible or cavalier (or are you against Vatican II as well?).

Messages such as:

> There is a mysterious bug causing occasional core dumps [...]
> It often makes mistakes [...]
> The grammar is incomplete and always will be [...]
> The value of 'tan' for arguments greater than about 2**31 is garbage.
> if you have two Pascal procedures in different blocks
>             with the same name, you lose.

and even:

>   Not bloody likely.
>   Don't base your financial plans on the currency conversions.

are honest indications of where problems may exist, and they do so
in language that can be enjoyed by the person reading the manual.  Just 
because the language is not on a par with "Segmentation fault, core 
dumped", or "Error R2702", or the all-too-famous "Syntax error" 
doesn't mean that people don't care that the errors are there or that
they didn't try to fix them -- it means that the error is recognized
and it means that the people writing the manuals are human.  It is
okay to smile while you are writing your code; enjoyment of ones work
allows him to produce more work of a higher quality.  

> [...] and the fact that C
> software seems to erode public confidence in software reliability on a
> regular basis (Nationwide Computer Network Infected By Worm; National 
> Telecommunications System Crashes), 

The fact that someone can break software does not mean that it is 
unreliable.  Can someone devoting lots of effort break YOUR code?

>   When is the C community going to clean up its act???

G.M.A.B. (give me a break)

> It appears that there is a real need to publicize software engineering 
> concepts throughout the C community, 

Throughout ALL software engineering communities.  Around here, the 
Fortran programmers need it a lot more than the C programmers -- not that
the C programmers don't.

> both directly through software
> engineering education and indirectly through a redesign of the C language
> to provide greater support for the software engineering process.  

The whole CONCEPT behind C is to give the programmer a significant amount
of power.  Power which can be used to do good things or bad.  C is a
language that does not coddle the programmer; if used with care, C
can allow a programmer to do great things.  If you believe that power
corrupts, however, feel free to use Ada.

> [...] If not,
> government regulation of the field will probably soon become inevitable.

AAAAaaaaahhhhhHHHrrrRRRrrgggggHHHHHH!  Government regulation of the private
sector?  Good God, man; don't you study your history?  How about Adam Smith
and the invisible hand?  If C software is not reliable, let the consumer
decide.  Letting the government in, well that's just stupid (unless you're
talking about Government contracts -- then retract all this stuff).

#undef FLAME

-- 
Wade Guthrie (evil@arcturus.UUCP)
Rockwell International; Anaheim, CA;  My opinions, not my employer's.

"All right, so I'm panicking, what else is there to do?"

chrisl@caen.engin.umich.edu (Chris Lang) (03/02/90)

In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   Under no circumstances should a DEFECTS section contain flippant
>   comments such as "I tinker a lot, so things break, but then I fix
>   them, hooray", "Not bloody likely", or other comments which indicate
>   a cavalier attitude toward software reliability.  
>
>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,
>   along with potential workarounds (if any) and the estimated date
>   of repair.  Now compare this with your typical Unix BUGS section.
>   
>
>   Bill Wolfe, wtwolfe@hubcap.clemson.edu

What, may I be so bold, gives you the right to declare what should or should
not be put in the documentation for a particular piece of code which you have
neither written nor worked on?  If such transgressions from the software
development community so distress you, why remain a member of it?  

 -Chris
-----
Chris Lang    University of Michigan, College of Engineering
home: 4622 Bursley             work: National Center for Manufacturing Sciences
      Ann Arbor, MI  48109           900 Victors Way, Suite 226
      (313) 763-1832                 Ann Arbor, MI  48108
chrisl@caen.engin.umich.edu          (313) 995-0300
"I hate quotations.  Tell me what you know."  - Ralph Waldo Emerson

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/03/90)

From evil@arcturus.UUCP (Wade Guthrie):
> [Unix BUGS comments]
> are honest indications of where problems may exist, and they do so
> in language that can be enjoyed by the person reading the manual.  

   If a currency conversion program is based on the exchange rates
   as of a given date, then this is a continuation of the specification 
   which does not belong in the DEFECTS section.   

   Under no circumstances should a DEFECTS section contain flippant
   comments such as "I tinker a lot, so things break, but then I fix
   them, hooray", "Not bloody likely", or other comments which indicate
   a cavalier attitude toward software reliability.  

   DEFECTS sections exist for the purpose of listing known areas in
   which an implementation does not correspond to the specification,
   along with potential workarounds (if any) and the estimated date
   of repair.  Now compare this with your typical Unix BUGS section.
   

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

cathy@gargoyle.uchicago.edu (Cathy Johnston) (03/03/90)

In article <00000NC@cdis-1.UUCP> tanner@cdis-1.UUCP (Dr. T. Andrews) writes:
[commenting on Bill Wolfe's complaint that units(1) is documented as only
 giving an approximate exchange rate...]
>
>Some of the things cited aren't amenable to change: do you really
>expect the currency conversion tables for units(1) to update
>themselves every morning from the currency tables in the paper?
>

Bill's complaint about units(1) is a whole lot sillier than that.  In very
fast markets, exchange rates change several times a second.  And what would
you like units(1) to use, Bill?  The price in Philadelphia?  London?
Tokyo?  Chicago?  Should it give the bid or the ask price?  Should it
use the spot quote, or maybe the price implied by the option synthetics?
How about the price from the futures markets adjusted for stochastic
interest rates?

I don't need the Wall Street Journal or the exchange rate ticker to tell
me that being a millionaire in Lira is no big deal and that "32 Swiss Francs
per kilogram" means that lamb chops in Zurich are very expensive.  Units(1)
is a simple little tool for getting a rough estimate, useful as far as it
goes, and *documented*as*just*that.  Calling it "evidence" that C programmers
are "unprofessional" and "irresponsible" is just, well, "dumb".

cathy

jseidman@jarthur.Claremont.EDU (James Seidman) (03/04/90)

In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From evil@arcturus.UUCP (Wade Guthrie):
>   If a currency conversion program is based on the exchange rates
>   as of a given date, then this is a continuation of the specification 
>   which does not belong in the DEFECTS section.   

The manual page for units(1) clearly states that the full list of available
units is contained in /usr/lib/units.  At least on my machine, this file
gives a clear reference for the source of the monetary conversions,
including date, newspaper, and exchange.  I'll assume you've studied a
little software engineering so you'll understand this:  The *program* is not
based on any exchange rates, it merely accesses a *data file* which contains
them.  Therefore any vendor can update this data file with newer values.

>   Under no circumstances should a DEFECTS section contain flippant
>   comments such as "I tinker a lot, so things break, but then I fix
>   them, hooray", "Not bloody likely", or other comments which indicate
>   a cavalier attitude toward software reliability.  

If I remember your initial post, the "tinker a lot" comment is from BBEMACS
and the "Not bloody likely" was from some similarly esoteric program.  I
don't know who wrote these programs or where you found them, but they may
just be some local hack.  Would you please check to find out where these
programs came from and limit yourself to condemning the appropriate authors?

>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,
>   along with potential workarounds (if any) and the estimated date
>   of repair.  Now compare this with your typical Unix BUGS section.

You never define a DEFECTS section.  Under what environment do you find
these?  In any case, my *typical* BUGS section is quite helpful.  If you
look at the BUGS section for jove(1), cc(1), more(1), msg(1), or any of a
host of other programs you will find no flippancy at all.

Also, if your complaints are with UNIX, might I suggest that you rant and
rave in the UNIX newsgroups?  Not all of UNIX is written in C, and by no
means is all that is written in C part of UNIX.  Having written thousands of
lines of C code under MS-DOS and VMS I can testify to this.

Lastly, if you are really concerned about this cavalier attitude, why don't
you write letters to some of the companies that do C programming?  They
might not realize how irresponsible their programmers are being.  I'm sure
that SCO, OSF, Microsoft, Borland, and all those other companies would know
exactly what to do with a letter from you explaining how they need to teach
their employees about software engineering.
-- 
-------------------------------------------------------------------------------
Jim Seidman, Harvey Mudd College, Claremont, CA 91711.  (714) 621-8000 x2026
DISCLAIMER: I don't even know if these are opinions, let alone those of
            anyone other than me.

goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/04/90)

In article <8212@hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes:
>    If a currency conversion program is based on the exchange rates
>    as of a given date, then this is a continuation of the specification 
>    which does not belong in the DEFECTS section.   

I see -- your latest strawman is that the manual page for units(1) does
not conform to *your* idea of proper documentation format.  Well, big
f---ing deal.  Many of us find it *helpful* to have caveats and bugs
called out separately instead of buried in the "specification".  ("It
ain't a bug -- it's a *Feetchur*!")  But I see your strategy -- your
new attack draws attention away from your original complaint about
units(1), which must have embarassed you horribly when you found out
about floating (gasp!) currency exchange rates.
 
>    Under no circumstances should a DEFECTS section contain flippant
>    comments such as "I tinker a lot, so things break, but then I fix
>    them, hooray", "Not bloody likely", or other comments which indicate
>    a cavalier attitude toward software reliability.  
> 
>    DEFECTS sections exist for the purpose of listing known areas in
>    which an implementation does not correspond to the specification,
>    along with potential workarounds (if any) and the estimated date
>    of repair.  Now compare this with your typical Unix BUGS section.

Well, I have, and except for the "estimated date of repair" part, I
find that most UNIX manpage BUGS sections already seem to offer just
this information.  (BTW, the EDoR of a bug is *not* a documentation
issues, a C issue, a UNIX issue, or even a programming issue.  It's
a product/release management issue.  Only after an EDoR has been
decided can it be documented.)

As for your examples, the ones with "flippant comments" seem to be
still more strawmen for your pathetic argument.  What the heck is
dab(1) anyway?  Are you perhaps confusing manpages for a real product
with manpages for locally programmed (and documented) extensions to
the system?

------------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/04/90)

From goudreau@larrybud.rtp.dg.com (Bob Goudreau):
> your original complaint about
> units(1), which must have embarassed you horribly when you found out
> about floating (gasp!) currency exchange rates.

   Right.  My self-managed IRA had a total return of 44.43% last year;
   how embarassing.  Maybe I should stop watching the Nightly Business
   Report so often, huh?

> What the heck is
> dab(1) anyway?  Are you perhaps confusing manpages for a real product
> with manpages for locally programmed (and documented) extensions to
> the system?

   Ask Richard D'Ippolito -- he originally posted the list to 
   comp.lang.ada.  Unfortunately, the article has already expired
   at my site.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/04/90)

In article <8223@hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes:
> > What the heck is
> > dab(1) anyway?  Are you perhaps confusing manpages for a real product
> > with manpages for locally programmed (and documented) extensions to
> > the system?
> 
>    Ask Richard D'Ippolito -- he originally posted the list to 
>    comp.lang.ada.  Unfortunately, the article has already expired
>    at my site.

So let me get this straight:  you're trotting out dab(1) as an example
of the "C Community's cavalier attitude on [sic] software reliability",
but you don't even have any idea of what dab is.  So how on earth do
you even know what language it's written in?

Not that the language matters anyway.  The following are all
*orthogonal* concepts (i.e., each may be varied independently of the
others):

1)  language used to program an application
2)  quality of design of the application
3)  presence or absence of documentation about bugs
4)  presence or absence of "flippant" remarks in the documentation

The only parameter that *does* depend (sometimes) on number 1 in the
list is:

5)  quality of implementation of the application

(But note that there are *many* more implementation decisions besides
language choice that play a far more important role in determining
quality of implementation.)

So far, you've shown us numerous strawmen that fall into categories
2, 3 and 4; none of those examples have anything to say about C (or
about any other programming language).  But you still haven't shown us
a relevant example from category 5:  an application whose quality of
implementation was lowered *solely due to the choice of C as the
programming language*.

Therefore, I ask you to take the "pep-C challenge":  either produce a
convincing number of such examples for us, or withdraw your original
statements. 

------------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/05/90)

From goudreau@larrybud.rtp.dg.com (Bob Goudreau):
> an application whose quality of
> implementation was lowered *solely due to the choice of C as the
> programming language*.

    1) Unix.  (Example: the problem in which the double-length password
                        was used by an intruder to bypass security, taking
                        advantage of C's lack of boundary checking)

    2) AT&T's phone network (Example: recent crash, which was attributable 
                                      to C having switch/break instead of
                                      a safer case statement)

    Now practically all programming languages are Turing-complete, so
    anything which can be written correctly can theoretically be written
    in any of them.  However, some programming languages (e.g., C) are
    more likely to leave errors undetected than others.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

fischer@iesd.auc.dk (Lars P. Fischer) (03/05/90)

In article <8147@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>   FILE(1)  It often makes mistakes.

Very good. Now give us a solution. Use Ada if you like. Any language.
Just write a program that will, given any file, tell me the nature of
the data in the file. In fact, I'd be happy to do the programming if
you'd just design the algorithm. 

/Lars
--
Lars Fischer,  fischer@iesd.auc.dk   | Q: How does a project get to be one
CS Dept., Univ. of Aalborg, DENMARK. | year late?  A: One day at a time.

fischer@iesd.auc.dk (Lars P. Fischer) (03/05/90)

In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,
>   along with potential workarounds (if any) and the estimated date
>   of repair.  Now compare this with your typical Unix BUGS section.

The BUGS section is also intended to point out problems you, as a user,
might have with a utility if you are not aware of limitations in the
design or the implementation. It is good practice to point out
implications of a design decision that the user might not be aware
of. 

/Lars
--
Lars Fischer,  fischer@iesd.auc.dk   | Q: How does a project get to be one
CS Dept., Univ. of Aalborg, DENMARK. | year late?  A: One day at a time.

rrr@eleazar.dartmouth.edu (Robin R. Reynolds) (03/05/90)

The Quixotan attacks by Bill Wolfe have not affected my attitudes on C or
Ada.  They do, however, suggest to me that the net is faced with a religious
fanatic of some sort.

Dogmatism gets no one anywhere.

Prognosis: Not Good.
Recommended Treatment: Ignore this guy.  He basks in your attention.

trt@rti.UUCP (Thomas Truscott) (03/05/90)

[insert favorite language bashing here]

In C I have typed:

	for (i = 0; i < 100; i++)
	    x[3][i] == 4;

In Pascal I have typed:

	for i := 1 to 100 do;
	    x[3][i] := 4;
		
In Ada I have typed:

	for i in x'range loop
	    x(3, i) := 4;
	end loop;


These are all "legal", but obviously not what I wanted.
A "lint"-like program, ideally the compiler itself,
could have warned me about these mistakes,
saving me a lot of trouble.

The C language (its formal definition) isn't especially dangerous.
But "C" (the practical definition) is typically extremely dangerous,
thanks to compilers that happily generate code for:

	*iwonder++;	/* why
	mycode();	/* doesn't */
	work = 1<<properly + 3;

without a whimper.  I remember hearing Steve Johnson (author of lint)
complaining that Management would not support additional work
on lint.  He had pages of notes on improvements he wanted to make.
That was 10 years ago.  I think lint has actually gotten worse since.

By its nature, a "lint"-like capability is hard to formalize.
I envision work on it as being fueled by examples of common programming
mistakes, and I can imagine fairly sophisticated analysis
going on.  As an analogy, I will use "spell" to find misspelled words
in this news article, but watt I really want is a proofreader.

Of course run-time checking is nice too.  Remember "Bcc", and "SafeC"?
They were commercial flops a few years back.
Only now is there a sufficient market for such a package.

In summary, I am saying that formal language design can go only so far
in preventing programming errors.  In fact, I am saying
it doesn't go very far at all.  Diagnostic compilers &etc
are an important part of the CA in CASE.
The "C" available on your platform may lack them.
So perhaps some other language, with better CA, should be used.
Blame it on "C", or the "C compiler".  Don't blame it on the "C language".

Of course I suppose people will blame it anyway.
Let me get the first crack.
None of the above errors would have happened in PL/1,
because in PL/1 I can simply type:

	x(4,*) = 3;

So there.
	Tom Truscott

karl@haddock.ima.isc.com (Karl Heuer) (03/05/90)

In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>    1) Unix.  (Example: the problem in which the double-length password
>                        was used by an intruder to bypass security, taking
>                        advantage of C's lack of boundary checking)

Every instance that I can think of where a password is required, getpass() is
used.  This routine does its own bounds-checking.  I don't suppose you have
any more data about this incident?

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

timk@xenitec.on.ca (Tim Kuehn) (03/05/90)

In article <19955@dartvax.Dartmouth.EDU> 
	rrr@eleazar.dartmouth.edu (Robin R. Reynolds) writes:
>The Quixotan attacks by Bill Wolfe have not affected my attitudes on C or
>Ada.  They do, however, suggest to me that the net is faced with a religious
>fanatic of some sort.
>
>Dogmatism gets no one anywhere.
>
>Prognosis: Not Good.
>Recommended Treatment: Ignore this guy.  He basks in your attention.

His activities last summer on misc.jobs.misc, making noxious posts about the
requirement for a BSCS to do any kind of programming and the absolute 
requirement to know all the latest research to even write such mundane 
things as accounting pkgs and the like seem to've spread to the area of 
languange bashing and dogmatic diatribes on the absolute superiority of Ada 
over all comers. 

Has this guy no shame? (Maybe it's time I pulled out my flamethrower of 
sarcasm and let him have another blast - the first one didn't seem to take 
too well...) 

+-----------------------------------------------------------------------------+
|Timothy D. Kuehn	       			       timk@xenitec.on.ca     |
|TDK Consulting Services			       !watmath!xenitec!timk  |
|871 Victoria St. North, Suite 217A					      |
|Kitchener, Ontario, Canada N2B 3S4 		       (519)-741-3623 	      |
|DOS/Xenix - SW/HW. uC, uP, DBMS. 		       Quality SW Guaranteed  |
+-----------------------------------------------------------------------------+

btrue@emdeng.Dayton.NCR.COM (Barry.True) (03/05/90)

In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>    1) Unix.  (Example: the problem in which the double-length password
>                        was used by an intruder to bypass security, taking
>                        advantage of C's lack of boundary checking)

What has boundary checking got to do with the C Programming Language? It is
a problem with the particular implementation or the programmer who coded
the program.

>
>    2) AT&T's phone network (Example: recent crash, which was attributable 
>                                      to C having switch/break instead of
>                                      a safer case statement)
>
>    Now practically all programming languages are Turing-complete, so
>    anything which can be written correctly can theoretically be written
>    in any of them.  However, some programming languages (e.g., C) are
>    more likely to leave errors undetected than others.
>

Again, this is a programmer/implementation problem. Name me one programming
language in which a program may be written correctly in which ALL PROGRAMS
CAN BE WRITTEN CORRECTLY REGARDLESS OF THE PROGRAMMER DOING THE WRITING OR
THE IMPLEMENTATION AND ENVIRONMENT IN WHICH THE PROGRAM IS BEING WRITTEN?
Please state facts pertaining to your argument that the C language itself is dangerous/faulty before criticising the C programming community in general. I
take great exception to your argument specifically because of this flaw in
logic.

evil@arcturus.UUCP (Wade Guthrie) (03/06/90)

H E L P !!!!

jseidman@jarthur.Claremont.EDU (James Seidman) writes:
>In article <8212@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:

>>From evil@arcturus.UUCP (Wade Guthrie):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>   If a currency conversion program is based on the exchange rates
>>   as of a given date, then this is a continuation of the specification 
>>   which does not belong in the DEFECTS section.   
[...]

I didn't say bad things about DEFECTS, et. al.  I'm one of the 'good'
guys!
-- 
Wade Guthrie (evil@arcturus.UUCP)
Rockwell International; Anaheim, CA;  My opinions, not my employer's.

"All right, so I'm panicking, what else is there to do?"

ggg@sunquest.UUCP (Guy Greenwald) (03/06/90)

In article <19955@dartvax.Dartmouth.EDU>, rrr@eleazar.dartmouth.edu (Robin R. Reynolds) writes [of Bill Wolfe]:

| Dogmatism gets no one anywhere.
| 
| Prognosis: Not Good.
| Recommended Treatment: Ignore this guy.  He basks in your attention.

It's hard to ignore him. Those who have followed postings to
misc.jobs.misc recognize Mr Wolfe as the person who frightened a lot
of job seekers into thinking they would never get hired because they
lacked a Master's Degree. In my opinion, it was a cruel performance.
The attack here is not on insecurity but on pride. Regardless of the
intellectual tone of the discussion, the tactic is identical: provoke
a number of people, get a lot of attention, argue relentlessly, shift
ground, ignore inconvenient rebuttals and send electronic hate mail
to alarm or anger opponents. We're not dealing with a nice person here,
nor a reasonable one, despite the veneer of intellectuality. The
discussion he provokes can be useful, however, as long as one
realizes that one will never convince Mr Wolfe. That's not what he's
about.

The issues of software reliability, the merits of one language vs.
another, how to document problems and when a product should be released
are important. They are worth discussing. A discussion of them can
be carried on with a sense of humor and moderation even if one of the
participants is humorless and extreme.

--G. Guy Greenwald II

jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins) (03/06/90)

In article <8223@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   Right.  My self-managed IRA had a total return of 44.43% last year;
>   how embarassing.

Get a clue, Wolfe.  Nobody gives a damn about your investment
performance, your sexual prowess, your standing with the Trilateral
Commission, or any other "credentials" you might publish.

This is comp.lang.c.  It's for people who use, or want to use C, well.

Perhaps you and Jim Giles should start comp.lang.i.hate.c, where you
could preach to the converted about the evils of C without bothering
those of us who have work to do.  (On the other hand, at least Giles
sticks to technical issues, and doesn't attempt to coerce our agreement
with appeal to irrelevant authority.)

Your attempts to attach blanket characteristics to the "C Community",
as if such a thing sprang into existence by mere mention of the name,
are laughable.  They don't acquire any more respect because you have IRAs.

-- 
Steve Jenkins N6UNI			jenkins@jpl-devvax.jpl.nasa.gov
Caltech/Jet Propulsion Laboratory	(818) 354-0162

joshua@athertn.Atherton.COM (Flame Bait) (03/06/90)

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   Under no circumstances should a DEFECTS section contain flippant
>   comments such as "I tinker a lot, so things break, but then I fix
>   them, hooray", "Not bloody likely", or other comments which indicate
>   a cavalier attitude toward software reliability.  

Why not?  Personally, I like the lighter tone often found in the BUGS 
section, and wish more documentation used it.  What do you think of 
programmers (or software engineers) laughing at work?  Pretty unprofessional,
right?  Ban it!  Does wearing a T-shirt to work which says "Bugs Rule" 
show a cavalier attitude toward software reliablity?  Maybe you can ban 
that too.  Jeeze.  Why don't you put up a sign: "programmers who have fun 
(or try to) will be branded `unreliable'".  

>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,

Unless you have the specification on line, this is pretty useless.  I'm glad
the BUGS (or DEFECTS) section lists things that the program doesn't do which 
a reasonable person might expect it to do, or the reverse.  I care more about
what the user expects, than what the (usually dusty) specification says.

The units program is a great example of this, a reasonable person might
be tempted to do his expense report based on the numbers it provides, but
the BUGS section warns him of the folly in this.

The BUGS section should should also list features which do not work and 
similar problems, if such exist.  But there should be few of these.

Joshua Levy                          joshua@atherton.com  home:(415)968-3718
                        {decwrl|sun|hpda}!athertn!joshua  work:(408)734-9822 

spicer@apollo.HP.COM (Steve Spicer) (03/06/90)

This 'discussion' sometimes seems more suited for alt.comp.religion than
anywhere else.  Therefore...

Mr. Wolf, I'd love to give up C and learn a new language, so please
name one for which the following statement is true:
"If it compiles, it must be correct."  Don't bother with C, Ada, Modula-2,
Pascal,FORTRAN,COBOL,Lisp,Prolog,Basic, or PL/1 -- I've seen programs
in each where the compiler did what the programmer said instead of
what the programmer meant.  I've blamed lousy training, lousy
documentation, lousy specs, and occasionally not enough sleep, but I
have NEVER blamed the language for my own shortcomings.

Steven Spicer

mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (03/06/90)

In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From goudreau@larrybud.rtp.dg.com (Bob Goudreau):
>> an application whose quality of
>> implementation was lowered *solely due to the choice of C as the
>> programming language*.
>
>    1) Unix.  (Example: the problem in which the double-length password
>                        was used by an intruder to bypass security, taking
>                        advantage of C's lack of boundary checking)

Ah, how quickly they forget.

I would like to point out that Unix was heralded as one of the first
(if not the first) operating system written in a high level language
in order that it could be maintained more easily.  This was a radical
concept back in the days of handcoded assembly language operating
systems.  Unfortunately, there are still some companies out there such
as Unisys and IBM that still code their major offerings in assembly
language, making maintenance and upgrades very difficult indeed.

The internet worm took advantage of a poorly designed peice of
software which is NOT part of UNIX per se, but rather a library call.
The library could have been written in any language.  It happened to
be written in C, but that is merely coincidental.

Sure, you are about to say that if it were written in Pascal, which
has stack/array bounds checking, the problem could not have occurred.
But there you are wrong as well.  Most Pascal compilers nowadays have
flags which allow the stack/bounds checking to be turned off, and they
usually are in distributed products (at least at the three companies
that I worked for that coded in Pascal) because they incur too much
overhead, thus slowing down the application.

It is unfair to condemn an entire operating system for a single flaw
by the way.  I will admit that Unix is not flawless, but then, you
can't find an operating system that is, so I'm not going to worry
about it...

>    2) AT&T's phone network (Example: recent crash, which was attributable 
>                                      to C having switch/break instead of
>                                      a safer case statement)

You can say that it is a problem with C, but there are other problems
which can occur in other languages with the same devastating effects,
for example misplaced semi-colons in Pascal, character reversal in
Assembly language and just plain typo's.  Most programming languages
have some level at which they have to trust the programmer.  Each
language is different, but they all have their faults.  C's is the
power of the programming language, Ada's is the sheer bulk of the
final code.  ("What do you mean that it is going to take over 150
Megabytes of Virtual memory just to compile your code?", a question
that I asked an individual who was requiring a machine reconfiguration
on a network that I was administring.)

>    Now practically all programming languages are Turing-complete, so
>    anything which can be written correctly can theoretically be written
>    in any of them.  However, some programming languages (e.g., C) are
>    more likely to leave errors undetected than others.

Like I said, at some point you have to trust the programmer.  If the
programmer knows what they are doing, knows the language and is alert,
90% of the bugs would be caught during coding.  However, programmers
are human, and errors are made.  That is life.

It will be interesting to see the first time that a well publicized
programming bug is discovered in an Ada application: here is a
multi-million dollar language that was designed by commitee to assure
"quality" software.  Are you going to say that Ada programmers produce
perfect code?  If you are, I can produce some that will tell you
exactly how wrong you are...




-- 
Mark H. Colburn                     If you don't make money off of it,
Open Systems Architects, Inc.	    it had better be either a religious
mark@Minnetech.MN.ORG		    experience or a hobby. 
							- Lance Cooper

gwollman@jhunix.HCF.JHU.EDU (Garrett A Wollman) (03/06/90)

In article <2169@sunquest.UUCP> ggg@sunquest.UUCP (Guy Greenwald) writes:
>We're not dealing with a nice person here,
>nor a reasonable one, despite the veneer of intellectuality. The
>discussion he provokes can be useful, however, as long as one
>realizes that one will never convince Mr Wolfe. That's not what he's
>about.

Even worse, he fiddled his address so that now I have to
put a
/wolf/h:j
into my ~/News/comp/lang/c/KILL file.  Not very nice indeed.  Now,
anyone who writes an article about how wolves interact with
far pointers to functions returning characters, will be ignored. :-)

-GAWollman
"..."
(got that, that was a "smiley")

-- 
"All societies are based on rules to protect pregnant women and children.
 . . . As racial survival is the only universal morality, no other bases
 is possible."           - Lazarus Long [RAH, _TEFL_]
---------------Hopkins doesn't *want* my opinions------------------------

freek@fwi.uva.nl (Freek Wiedijk) (03/06/90)

>Sure, you are about to say that if it were written in Pascal, ...

Wrong.  Completely wrong.  He was about to say that "if it were written
in Ada, ..."

--
Freek "the Pistol Major" Wiedijk                  Path: uunet!fwi.uva.nl!freek
#P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**

eric@snark.uu.net (Eric S. Raymond) (03/06/90)

In <16085@haddock.ima.isc.com> Karl Heuer wrote:
> In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
> >    1) Unix.  (Example: the problem in which the double-length password
> >                        was used by an intruder to bypass security, taking
> >                        advantage of C's lack of boundary checking)
> 
> Every instance that I can think of where a password is required, getpass() is
> used.  This routine does its own bounds-checking.  I don't suppose you have
> any more data about this incident?

This sounds like a somewhat garbled description of a known hole in SunOS. As
Sun still hasn't fixed it, I shall say no more about it here. E-mail inquiries
from root or anyone whose name I can instantly recognize as a Good Guy will be
answered in more detail.
-- 
      Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)

kdq@demott.COM (Kevin D. Quitt) (03/07/90)

Bill,

    I'm sorry, but my karma just ran over your dogma.

kdq
-- 



Kevin D. Quitt                          Manager, Software Development
DeMott Electronics Co.                  VOICE (818) 988-4975
14707 Keswick St.                       FAX   (818) 997-1190
Van Nuys, CA  91405-1266                MODEM (818) 997-4496 Telebit PEP last
34 12 N  118 27 W                       srhqla!demott!kdq   kdq@demott.com

ggg@sunquest.UUCP (Guy Greenwald) (03/07/90)

In article <4414@jhunix.HCF.JHU.EDU>, gwollman@jhunix.HCF.JHU.EDU (Garrett A Wollman) writes:
| anyone who writes an article about how wolves interact with
| far pointers to functions returning characters, will be ignored. :-)
| 
| -GAWollman
| "..."
| (got that, that was a "smiley")

That's not a smiley, that's a belly laugh!

--G. Guy Greenwald II

woody@eos.UUCP (Wayne Wood) (03/07/90)

In article <1990Mar5.144433.4293@xenitec.on.ca> timk@xenitec.UUCP (Tim Kuehn) writes:
>
>His activities last summer on misc.jobs.misc, making noxious posts about the
>requirement for a BSCS to do any kind of programming and the absolute 
>requirement to know all the latest research to even write such mundane 
>things as accounting pkgs and the like seem to've spread to the area of 
>languange bashing and dogmatic diatribes on the absolute superiority of Ada 
>over all comers. 
>
>Has this guy no shame? (Maybe it's time I pulled out my flamethrower of 
>sarcasm and let him have another blast - the first one didn't seem to take 
>too well...) 
>

yeah tim... i remember this dickheads postings from then...  let me save
you some time and effort...

[FLAME ON]

listen shithead... if you don't like the way the fucking package is written,

since you are obviously the greatest thing to hit programming since Knuth,

gtake the language of your choice and rewrite the goddamn thing.

when you have done this, AND NOT UNTIL, come back and tell us how you

cured the bugs.  then we might be impressed.

[FLAME OFF]


/***   woody   ****************************************************************
*** ...tongue tied and twisted, just an earth bound misfit, I...            ***
*** -- David Gilmour, Pink Floyd                                            ***
****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/

hamish@mate.sybase.com (Just Another Deckchair on the Titanic) (03/08/90)

In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>	[...]
>    Now practically all programming languages are Turing-complete, so
>    anything which can be written correctly can theoretically be written
>    in any of them.  However, some programming languages (e.g., C) are
>    more likely to leave errors undetected than others.

IMO this is the first time on this forum that Bill has articulated the
real issue behind the recent postings without needlessly inflamotory
adjectives and irrelevant "evidence". What he says above is (again,
IMO) correct (but vague enough to be unasailable) - and rather
different to saying that the "C community" (whatever *that* may be...)
has a cavalier attitude towards software engineering.

But what troubled me during the recent flame fest has been that the
discussion has (deliberately?) revolved around  the *easy problem* in
software engineering - particular language insecurities. This is
something that with careful supervision and standard engineering
techniques is solvable in a way that the Big Problems - understanding
and specifying the problem and solution in manageable, understandable,
coherent and provably correct ways- are not. Not an easy task.

In that context, particular (and debatable) insecurities in C are
barely worth mentioning except in passing.

Perhaps the focus was on language insecurites *because* we can't solve
the bigger problems - and because it's the easier target?

	Hamish
----------------------------------------------------------------------------
Hamish Reid           Sybase Inc, 6475 Christie Ave, Emeryville CA 94608 USA
+1 415 596-3917       hamish@sybase.com       ...!{mtxinu,sun}!sybase!hamish

jamiller@hpcupt1.HP.COM (Jim Miller) (03/10/90)

>> [Unix BUGS comments]
>> are honest indications of where problems may exist, and they do so
>> in language that can be enjoyed by the person reading the manual.  
>
>   Under no circumstances should a DEFECTS section contain flippant
>   comments such as "I tinker a lot, so things break, but then I fix
>   them, hooray", "Not bloody likely", or other comments which indicate
>   a cavalier attitude toward software reliability.  
>
>   DEFECTS sections exist for the purpose of listing known areas in
>   which an implementation does not correspond to the specification,
>   along with potential workarounds (if any) and the estimated date
>   of repair.  Now compare this with your typical Unix BUGS section.
>
>   Bill Wolfe, wtwolfe@hubcap.clemson.edu

.flame on
If you don't like the BUGS comments, don't read them, get some "real"
documentation instead.  This note is only 1/4 flippant.  Un*x documentation
looks like it is written by-for-and-to fun-(and work)-loving programmers.
If fun in your information bothers you, go elsewhere.  One reason I LIKE
the un*x community is because of the attitude you are attacking.  It is
written for programmers, not the rest of the world.  Other documentation is
being written for the rest.  People are making money informing the rest of
the world, especially  the various thought police who aggree with
the above "> " comments.
.flame off

   Jim - that's my ox you're goring - miller

reggie@dinsdale.nm.paradyne.com (George W. Leach) (03/16/90)

In article <8616@sybase.sybase.com> hamish@sybase.com.(Just Another Deckchair on the Titanic) writes:

>Perhaps the focus was on language insecurites *because* we can't solve
>the bigger problems - and because it's the easier target?

    It is easier also to find a "silver bullet" that one can champion.
How often have we seen this in the past?

George

George W. Leach					AT&T Paradyne 
(uunet|att)!pdn!reggie				Mail stop LG-133
Phone: 1-813-530-2376				P.O. Box 2826
FAX: 1-813-530-8224				Largo, FL 34649-2826 USA