C Community's Cavalier Attitude On Software Reliability
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:
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, wtw...@hubcap.clemson.edu
John A. Weeks III
> 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 jo...@newave.mn.org
NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================
Richard O'keefe
but I really couldn't let Bill Wolfe's message pass unchallenged.
In article <81...@hubcap.clemson.edu>, wtw...@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.
Dennis Ritchie
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 (wtw...@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
Barry.True
>
> 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-)!!!
Jim Harkins
(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
> 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 Ja...@Gore.Com boulder!gore!jacob
Andrew Balinsky
>Lots of stuff.
We are just about finished with the verification mud-sling-fest. Let's not
jump into personal attacks on this subject. Besides, the merits/demerits of
C ought to be discussed in comp.lang.c.
--
Andrew Balinsky (301)454-8094|For my purpose holds to sail beyond the sunset
UMD, College Park, MD 20742 |And to the baths of all the western stars
bali...@cs.umd.edu | until I die.
..uunet!mimsy!balinsky | -Tennyson, "Ulysses"
Henry Spencer
> 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 he...@zoo.toronto.edu
Peter da Silva
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. <pe...@ficc.uu.net>.
/ \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
v "Have you hugged your wolf today?" `-_-'
Martin Weitzel
> of by many as having an unprofessional and irresponsible attitude
> toward software reliability:
>
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, wtw...@hubcap.clemson.edu
>
--
Martin Weitzel, email: mar...@mwtech.UUCP, voice: 49-(0)6151-6 56 83
David Wolverton
> > 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
d...@attunix.att.com
Karl Heuer
>In article <81...@hubcap.clemson.edu> wtw...@hubcap.clemson.edu (Bill Wolfe) writes:
>> SCANF(3S) The success of literal matches and suppressed
>> assignments is not directly determinable.
>
Since nobody else has said it yet, I will:
Fixed in ANSI C, via the "%n" directive.
Karl W. Z. Heuer (ka...@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
Mark H. Colburn
> 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
ma...@Minnetech.MN.ORG experience or a hobby.
- Lance Cooper
Richard O'keefe
: 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 <16...@haddock.ima.isc.com>,\
ka...@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.
Larry A. Shurr
>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!l...@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!!!)
Tom Neff
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.
Arturo Perez x6739
>
> 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:
>
>
> 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, wtw...@hubcap.clemson.edu
>
Arturo Perez
ComputerVision, a division of Prime
ape...@cvbnet.prime.com
Too much information, like a bullet through my brain -- The Police
Karl Heuer
>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.
Martin Weitzel
>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
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".
Dr. T. Andrews
) 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
Wade Guthrie
> 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 (ev...@arcturus.UUCP)
Rockwell International; Anaheim, CA; My opinions, not my employer's.
"All right, so I'm panicking, what else is there to do?"
Chris Lang
> 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, wtw...@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
chr...@caen.engin.umich.edu (313) 995-0300
"I hate quotations. Tell me what you know." - Ralph Waldo Emerson
William Thomas Wolfe, 2847
> [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.
Cathy Johnston
[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
James Seidman
> 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.
Bob Goudreau
billwolf%hazel.cs.c...@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 goud...@dg-rtp.dg.com
Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau
USA