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
William Thomas Wolfe, 2847
> 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, wtw...@hubcap.clemson.edu
William Thomas Wolfe, 2847
>> your original complaint about
>> units(1), which must have embarassed you horribly when you found out
>> about floating (gasp!) currency exchange rates.
>
> the Nightly Business Report so often, huh?
Oh, by the way, Bob, you'll be pleased to know that Reuters (which
supplies the Nightly Business Report with its market data, including
currency quotes) is delivering that market data using Ada software...
the introduction of Ada technology into Reuters was described at the
ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!!
Bill Wolfe, wtw...@hubcap.clemson.edu
Bob Goudreau
billwolf%hazel.cs.c...@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?
>
> 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
billwolf%hazel.cs.c...@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes:
> >> your original complaint about
> >> units(1), which must have embarassed you horribly when you found out
> >> about floating (gasp!) currency exchange rates.
> >
> > the Nightly Business Report so often, huh?
>
> supplies the Nightly Business Report with its market data, including
> currency quotes) is delivering that market data using Ada software...
> the introduction of Ada technology into Reuters was described at the
> ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!!
Say what?
I was talking about your original criticism of units(1) for the way
its manpage admitted that the program had no way of automatically
updating its exchange-rate information in real-time. You came to
the embarassingly stupid conclusion that this limitation was somehow
a fault of the C programming language. But go ahead and defend that
conclusion if you must....
William Thomas Wolfe, 2847
> I was talking about your original criticism of units(1) for the way
> its manpage admitted that the program had no way of automatically
> updating its exchange-rate information in real-time. You came to
> the embarassingly stupid conclusion that this limitation was somehow
> a fault of the C programming language. But go ahead and defend that
> conclusion if you must....
No, it was an example of the C community's cavalier attitude
toward software reliability. The comment "Don't base your
financial plans on the output", or words to that effect, were
a) inappropriate, since the static nature of the rates is part
of the specification and should not be listed in the defects
section, and b) irresponsible, since it indicates a flippant
approach to the reliability of the output.
Bill Wolfe, wtw...@hubcap.clemson.edu
William Thomas Wolfe, 2847
> 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, wtw...@hubcap.clemson.edu
Scott MacHaffie
> supplies the Nightly Business Report with its market data, including
> currency quotes) is delivering that market data using Ada software...
> the introduction of Ada technology into Reuters was described at the
> ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!!
So what's your point? Do you understand the difference between hardware and
software? Do you even realize that there is a difference?
Hardware is the physical parts of a computer such as the disk drives,
monitors, terminals, modems, etc.
Software is the programs that run on a computer.
A computer program (software) can NOT provide CURRENT currency exchange rates
without hardware which is designed to collect the currency rates from somewhere.
ADA SOFTWARE can not deliver market reports without reading data from the
market using a modem or a similiar HARDWARE device.
If you're going to be stupid, please take it to an appropriate news group,
such as alt.stupid.users.who.dont.have.a.clue.and.never.will.
Scott MacHaffie
Scott MacHaffie
> financial plans on the output", or words to that effect, were
> a) inappropriate, since the static nature of the rates is part
> of the specification and should not be listed in the defects
You will be happy to know that in the version of Unix we are running
here, the man page for "units" has nothing resembling a BUGS section.
Therefore, the "units" program at this site is perfect. It is an
example of high-quality software engineering because the programmers
didn't include any of those stupid "bugs" sections in the man page.
Do you feel stupid yet? You should.
Raymond Chen
> a) inappropriate, since the static nature of the rates is part
> of the specification and should not be listed in the defects
> section,
Okay, part of the problem is not realizing that the BUGS section
of a man page is misnamed.
The BUGS section is also somewhat misnamed. Defects reported
here aren't so much bugs as shortcomings---simple bugs should
be fixed before the command in installed.
-Kernighan and Pike
"The UNIX Programming Environment"
p. 311
It really should be called "POTENTIALLY PROBLEM-CAUSING BEHAVIOR". So
defects in the specification or any behavior which someone might
possibly think is a bug (even if it isn't) go into the BUGS section.
For example, the sentence
The precedence rules are somewhat nonintuitive.
belongs in the BUGS section even though it isn't a bug.
Doug Schmidt
> b) irresponsible, since it indicates a flippant
> approach to the reliability of the output.
Lord knows we don't want flippant manual pages. What we need are more
software engineering cacademoids[1]. That'll solve the software
crisis right quick... 1/2 ;-)
Doug
----------------------------------------
[1] cacademoid n. [fr. L caca (feces) + academe + -oid, fr. Gk eidos
(form or shape)]: The lowest creature in higher education; typically,
a sexually repressed, humorless, and self-impressed professor or
administrator afraid of the real world, incapable of teaching and
producing useful research, and hostile to new ideas; found in every
kind of academic institution, cacademoids love to serve on committees,
despise students, and venerate their inferior superiors. "Professor
Freddy Cavity claims there are no dialect terms for genitals in
American English. What a cacademoid!"
-- Reinhold Aman, in "What's the Word For ...?", Harper's, Feb. 1990
----------------------------------------
--
facilis descensus avernus
----------------------------------------
sch...@ics.uci.edu (ARPA)
office: (714) 856-4043
Michael Friedman
I disagree.
On point A you are technically correct - the possibly unreliable
nature of the rates is part of the spec. On the other hand, from the
point of view of producing good results, that note is in exactly the
right place.
It isn't as important with something like Units that has a 2 page man
entry, but say we have something like csh. I'm not going to read
through a hundred pages looking for caveats and warnings. I want them
in one simple clear easy to use location - the Bugs section. One of
the most important things about documentation is to make it useful to
the reader. That's a lot more important than placing everything
exactly where it belongs according to some static criteria.
On point B I again disagree.
Irresponsible is when someone does something careless or possibly
damaging. For example, it would be irresponsible to use Units in a
financial application without reading the Bugs section.
Flippant comments in documentation are more evidence that people
aren't overly worreid about frightening away customers, probably
because most customers don't read UNIX man pages.
A flippant approach to reliability is bad. Why are jokes about
reliability bad?
--
The passing of Marxism-Leninism first from China and then from the
Soviet Union will mean its death as a living ideology ... . For while
there may be some isolated true believers left in places like Managua,
Pyongyang, or Cambridge, MA ... - Francis Fukuyama
Lars P. Fischer
> No, it was an example of the C community's cavalier attitude
> toward software reliability. The comment "Don't base your
> financial plans on the output", or words to that effect, were
> a) inappropriate, since the static nature of the rates is part
> of the specification and should not be listed in the defects
> section, and b) irresponsible, since it indicates a flippant
> approach to the reliability of the output.
a) Yes, it's part of the specs, but it can't hurt to keep the user
informed, can it? The user might not realize that using a static
database has this effect.
b) Nonsense. What would *you* have done? You might not like an
occasional humorous remark, but calling it irresponsible is plain
silly.
/Lars
--
Lars Fischer, fis...@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.
Lars P. Fischer
> 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 P. Fischer
> 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.
Robin R. Reynolds
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.
Thomas Truscott
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 Heuer
> 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?
D'Arcy J.M. Cain
Where do you work? In a monastary? Lighten up will ya. Just because
someone is aware of the limitations of their program doesn't mean they
have to hold a funeral over it. Besides the comment "Don't base your
financial plans on the output" doesn't sound all that flippant. I would
take that admonition to heart if I was making multi-currency decisions.
Sheesh! Someone give the guy a black armband while the rest of us get
back to the party.
--
D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all
D'Arcy Cain Consulting | the government we pay for.
West Hill, Ontario, Canada |
(416) 281-6094 |
Tim Kuehn
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 ti...@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 |
+-----------------------------------------------------------------------------+
Mike Percy
I don't recall ever having read the specification to units...has anyone
else? I'd rather have some sort of statement in the documentation
(on-line or otherwise) that the user would commanly have access to
rather than some (possibly) non-existent specification documentation
that users won't usually be provided with.
Re: point b)
irresponsible and flippant are relative terms which are a matter of opinion.
If its your opinion that the aforementioned comments are flippant, well
that's your opinion. I tend to get bored wading through bland documentation
written by software engineers and technical writers. The interjection of
some light-heartedness is hardly a crime, particularly when the software
is not related to the safety of anyone.
C is not the problem here. Any language can produce horrible constructions
and programs. Any programmer can produce comments and documentation which
does not meet Bill Wolfe's stringent requirements, daresay that no one but
Bill can meet Bill's requirements, since apparently what Bill wants is
perfection in all its boring splendor.
>
> Bill Wolfe, wtw...@hubcap.clemson.edu
>
Tom Neff
> toward software reliability. The comment "Don't base your
> financial plans on the output", or words to that effect, were
> a) inappropriate, since the static nature of the rates is part
> of the specification and should not be listed in the defects
> section, and b) irresponsible, since it indicates a flippant
> approach to the reliability of the output.
This is pretty silly.
Do Ada fans ever strike you-all as just a teeny bit defensive? :-)
If the original poster wants a serious discussion, then some heavy duty
definition of terms (starting with what's a "C community") is in order.
But something tells me that's not quite what's going on here... maybe we
should all just smile and say, "Very good Bill!" and move on to the
next thing.
--
"Nature loves a vacuum. Digital \O@/ Tom Neff
doesn't." -- DEC sales letter /@O\ tn...@bfmny0.UU.NET
Barry.True
> 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.
Wade Guthrie
jsei...@jarthur.Claremont.EDU (James Seidman) writes:
>In article <82...@hubcap.clemson.edu> billwolf%hazel.cs.c...@hubcap.clemson.edu writes:
>>From ev...@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 (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?"
Guy Greenwald
| 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
Steve Jenkins
> 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 jen...@jpl-devvax.jpl.nasa.gov
Caltech/Jet Propulsion Laboratory (818) 354-0162
Henry Spencer
>If you're going to be stupid, please take it to an appropriate news group,
>such as alt.stupid.users.who.dont.have.a.clue.and.never.will.
If everybody just puts Bill Wolfe in their kill files, comp.lang.c will
be a better (and less noisy) place.
--
MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology
an Operating System. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Ozan Yigit
> toward software reliability.
No, it is a programmer's realistic attitute towards the limitations of an
often-useful program. It has nothing to do with the so-called C Community.
But wait !!! You exist on this network precisely because of other programs
of the type you criticise. Or maybe... you are a badly written program
yourself !!! :-) A PC program called "racter" has better conversational
skills than you do.
Did you ever post onto the net under the name "Ken Arndt" ??? [Sorry Ken !]
oz
--
There are two kinds of fool. Internet: o...@nexus.yorku.ca
One says, "This is old, and therefore good" Uucp: uunet!utai!yunexus!oz
And one says "This is new, and therefore Better" Bitnet: oz@[yulibra|yuyetti]
John Brunner (The Shockwave Rider) Phonet: +1 416 736-5257x3976
John F Nixon
> 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?
(I know this has nothing to do with C, or software engineering...)
Gee, sounds like you are really pushing it; either you are making extremely
risky decisions with your retirement money (not very smart), or you made a
bad career choice when you decided to work with computers. Warren Buffet
will need a successor one day... :-) :-)
(ok, ok, I'll learn...)
----
jni...@atl.ge.com ...steinmetz!atl.decnet!jnxion
Charles Hannum
In article <1990Mar5....@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer)
says:
>
>In article <10...@june.cs.washington.edu>
>mach...@fred.cs.washington.edu.cs.washington.edu (Scott MacHaffie) writes:
>>If you're going to be stupid, please take it to an appropriate news group,
>>such as alt.stupid.users.who.dont.have.a.clue.and.never.will.
>
>If everybody just puts Bill Wolfe in their kill files, comp.lang.c will
>be a better (and less noisy) place.
VM Netnews doesn't support Kill files. <HEAVY SIGH>
I just ignore the ignorant.
Virtually,
- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
(That's Charles to you!) "To life immortal!"
cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
Flame Bait
> 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 jos...@atherton.com home:(415)968-3718
{decwrl|sun|hpda}!athertn!joshua work:(408)734-9822
Steve Spicer
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
Chris Lang
> toward software reliability. The comment "Don't base your
> financial plans on the output", or words to that effect, were
> a) inappropriate, since the static nature of the rates is part
> of the specification and should not be listed in the defects
> section, and b) irresponsible, since it indicates a flippant
> approach to the reliability of the output.
Why don't we ALL chip in and buy Bill a nice thesaurus, so he can come up
with synonyms for "cavalier", "flippant", "irresponsible", and "inappropriate"?
Each of these words, all very subjective opinions, has permeated most of his
postings so far...and seem to form the backbone of his argument. Maybe we
could also pay for him to take a course in discussion which relies on facts and
logical debate rather than repetitive babble, as well.
(Let's see...how many synonyms for "bore" can we find...)
-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
Mark H. Colburn
>> 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
ma...@Minnetech.MN.ORG experience or a hobby.
- Lance Cooper
Garrett A Wollman
>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 Wiedijk
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 S. Raymond
> In article <82...@hubcap.clemson.edu> billwolf%hazel.cs.c...@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 = er...@snark.uu.net (mad mastermind of TMN-Netnews)
Kevin D. Quitt
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 k...@demott.com
Guy Greenwald
| 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
Jerome_V...@cup.portal.com
I agree with Bill Wolfe about the quoted statements in the "BUGS"
sections of the man pages. Try to pretend you are a manager is
a customer shop who is looking at the man pages before investing
your company's money in Unix based systems. While I like humor,
these sections are very poor customer relations. The C/Unix community
is not alone in making this mistake but that is not a reason to
continue making mistakes or refrain from correcting past mistakes
where possible.
Not looking at documents from the customer perspective is one of
the marks of engineers. We all need to improve in this area.
Jerome Vollborn
(Jerome_...@cup.portal.com or
uunet!lci386!jerome)
John Hascall
}In article <82...@hubcap.clemson.edu> billwolf%hazel.cs.c...@hubcap.clemson.edu writes:
}> [blah, blah, blah...]
}
}Why don't we ALL chip in and buy Bill a nice thesaurus, so he can come up
}with synonyms for "cavalier", "flippant", "irresponsible", and "inappropriate"?
}(Let's see...how many synonyms for "bore" can we find...)
Uh, how about "boor" or perhaps even "boar"?
John Hascall / has...@atanasoff.cs.iastate.edu
C is a Ferrari, Ada a Volvo, drive what you can handle.
Guy Shaw
> The BUGS section is also somewhat misnamed. Defects reported
> here aren't so much bugs as shortcomings
[...]
>
> It really should be called "POTENTIALLY PROBLEM-CAUSING BEHAVIOR".
Some flavors of UNIX(TM) come with separate CAVEATS and BUGS sections in the
commands reference manual. Interactive does this. At least they used to long
ago; I don't know if they still do. I wish this were a more common practice.
--
Guy Shaw
Paralogics
paralogics!sh...@uunet.uu.net or uunet!paralogics!shaw
Wayne Wood
>
>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 ***
****** wo...@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/
Guy Shaw
Mr. Wolf's posting about "the C community's cavalier attitude toward software
reliability" encompassed enough subject matter that it was bound to generate
many threads about various aspects (sort of like sitcom spin-offs). In this
article, I address only the issue of the appropriateness of lumping all manner
of shortcomings into the BUGS section of a reference manual.
In article <1990Mar4.2...@oracle.com>, mfri...@oracle.com (Michael Friedman) writes:
> In article <82...@hubcap.clemson.edu> billwolf%hazel.cs.c...@hubcap.clemson.edu writes:
> > No, it was an example of the C community's cavalier attitude
> > toward software reliability. The comment "Don't base your
> > financial plans on the output", or words to that effect, were
> > a) inappropriate, since the static nature of the rates is part
> > of the specification and should not be listed in the defects section
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > [...]
>
> I disagree.
>
> On point A you are technically correct - the possibly unreliable
> nature of the rates is part of the spec. On the other hand, from the
> point of view of producing good results, that note is in exactly the
> right place.
[...]
> entry, but say we have something like csh. I'm not going to read
> through a hundred pages looking for caveats and warnings.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
> I want them
> in one simple clear easy to use location - the Bugs section. [...]
Yes, Mr. Wolf has a point and so does Mr. Friedman, but there are more
possibilities than just the two extremes of a) lumping things in the BUGS
section and b) distributing caveats throughout the reference manual.
To be fair, Mr. Wolf did not offer (b) as the only alternative. In fact,
he said nothing more specific about how he would organize a reference manual.
Mr. Friedman's reaction is very understandable, though, because caveats
sprinkled throughout the reference manual, where each subject naturally arises,
*is* the alternative style that actually occurs in AT&T UNIX reference manuals.
And, like diseases of the lymphatic system, it is nearly impossible to treat
with surgery.
The approach of having separate CAVEATS and BUGS sections solves the problem
of where to put limitations, shortcomings, non-intuitive behavior, etc. without
calling it all BUGS, and still lists them in one easy to find place.
It is more precise. Nothing else is sacrificed for the the gain in precision.
This is more than just armchair reference manual designing. I have used
slightly non-standard (improved!) UNIXoid manuals that do it this way.
It works for me. I wish it were more common practice. To the reference manual
designers at AT&T: try it, you'll like it.
hepburn m stroman
>> From goud...@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.
>>
>> [I replied:] Right. My self-managed IRA had a total return of
>> the Nightly Business Report so often, huh?
>
> supplies the Nightly Business Report with its market data, including
> currency quotes) is delivering that market data using Ada software...
> the introduction of Ada technology into Reuters was described at the
> ACM SIGAda Tri-Ada '88 conference. Sorry you missed it!!!
>
>
Is that all that relevant? Software is written in a variety of
for a variety of reasons. Reuters chose Ada. So what? It could have
been a choice based on convenience, or government requirement (which
seems to be the big reason for using Ada). If your comment is intended
to show Ada is supeior because a _real_ product uses it, then perhaps I
should list the hundreds (thousands?) of commercial products that use C
(or cobol or fortran). Many applications were and are being developed
in them. Since more programs are written in C, I suppose your logic
must lead to the concluion C is superior (after all, more real software
is written in it)
Oh, and about your IRA. I'm impressed, but it is irrelevant to your
point in your original post (namely, that units() was an example of bad
C coding practice.) As a software engineer, you
really should have researched units() and discovered the use of a data
file before your initial posting. Also, to add validity to your original
point, it would have been nice to see some proof that the few programs
described were C-language products.
> Bill Wolfe, wtw...@hubcap.clemson.edu
>
Jim Harkins
>In article <490595b...@moth.engin.umich.edu> chr...@caen.engin.umich.edu (Chris Lang) writes:
>}In article <82...@hubcap.clemson.edu> billwolf%hazel.cs.c...@hubcap.clemson.edu writes:
>}(Let's see...how many synonyms for "bore" can we find...)
>
> Uh, how about "boor" or perhaps even "boar"?
You forgot the obvious, "wolfe". Has anybody noticed how testy the ada people
get when someone posts anything the least bit disparaging about ada in
comp.lang.ada? So why do we let this dweeb cause us so much consternation?
--
jim jharkins@sagpd1
"My hope is that we can use tariffs to force Japan to open their markets to
imported goods. My fear is I'll be forced to buy lousy American made stuff."
Just Another Deckchair on the Titanic
> 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 ham...@sybase.com ...!{mtxinu,sun}!sybase!hamish
Tony Sanders
> approach to the reliability of the output.
because we have a "flippant approach to the reliability of the output."
I guess he would like all software people to wear ties and not have sense
of humor. Maybe we should all get MBA's while we are at it. Hey,
lets all take up COBAL, there is no way in h*ll that you can have
a flippant approach to ANYTHING in COBAL :-)
-- sanders The 11th commandment: "Thou shalt use lint"
For every message of the day, a new improved message will arise to overcome it.
Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders
Jim Miller
>> 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
> DEFECTS sections exist for the purpose of listing known areas in
> which an implementation does not correspond to the specification,
> of repair. Now compare this with your typical Unix BUGS section.
>
> Bill Wolfe, wtw...@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
Jim Miller
>the marks of engineers. We all need to improve in this area.
The Un*x man pages tend to be for programmers, especially the ones
under attack/consideration. "WE" are the users for most the subjects under
definition. The Manager is the buyer, not the user. I will maintain that
the pages are more useful to the user (me) the way they are, even if not
as pretty to the buyer. If the buyer asks his customers (the programmers)
which they prefer instead of telling him what he needs (and how long it
will take, and what exactly will be in it, and never mind the two are
not compatible ...) the man pages as they exist will win out over
"professional" (suit, tie, and useless) ones.
jim - i like them, i use them, i do not like the alternative - miller
m...@cs.rit.edu
>Perhaps the focus was on language insecurites *because* we can't solve
>the bigger problems - and because it's the easier target?
Hmm -- and interesting point, and one that's crossed my mind from time
to time. It's the software game's variant of the "Common Council Syndrome":
City Common Council's will blithely pass an appropriation for many millions
of dollars to fix some problem, and then spend hours arguing over smoking
in public places or whether dog owners should carry pooper-scoopers when
taking their pets for a walk. The reason is that it's hard to understand
with any specificity multi-million dollar appropriations, but everyone
has feels they are an expert on smoking and dog doo. Maybe this is just
a limitation of being human??
Direct responses to alt.philosopy :-)
Mike Lutz
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {rutgers,cornell}!rochester!rit!mjl
INTERNET: m...@csrit.edu
Richard Goerwitz
>>Not looking at documents from the customer perspective is one of
>>the marks of engineers. We all need to improve in this area.
>
> tie, and useless) ones.
Sorry, SCO Xenix (and I'll bet SCO Unix as well) doesn't have a "bugs"
section in its manuals. They call it "comments" or the like. Xenix
is probably the most popular Unix variant ever to have hit the market.
It does seem a bit childish to, in effect, censor the word "bugs" from
manual pages. The statement that the "suit and tie" straitjacket will
never win out, however, just isn't true. The suits and ties invariably
get control of any situation they find it useful to control :-(. It's
a sad by-product of our economic system.
-Richard L. Goerwitz goer%sop...@uchicago.bitnet
go...@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer
Henry Spencer
>... SCO Xenix (and I'll bet SCO Unix as well) doesn't have a "bugs"
>section in its manuals. They call it "comments" or the like...
>It does seem a bit childish to, in effect, censor the word "bugs" from
This is common. The reason is the US's demented liability laws, which
make sane companies reluctant to do anything which might possibly be
misconstrued as hinting at knowledge of defects in products.
--
MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology
an Operating System. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
D'Arcy J.M. Cain
>
>I agree with Bill Wolfe about the quoted statements in the "BUGS"
>sections of the man pages. Try to pretend you are a manager is
>a customer shop who is looking at the man pages before investing
>your company's money in Unix based systems.
You forgot the smiley. A manager looking at man pages before buying
UNIX! HAHAHAHAHAHA.
> While I like humor,
Yah, it shows.
--
D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all
D'Arcy Cain Consulting | the government we pay for.
West Hill, Ontario, Canada |
(416) 281-6094 |
Andrew P. Mullhaupt
> Sorry, SCO Xenix (and I'll bet SCO Unix as well) doesn't have a "bugs"
> section in its manuals. They call it "comments" or the like. Xenix
> is probably the most popular Unix variant ever to have hit the market.
> It does seem a bit childish to, in effect, censor the word "bugs" from
> manual pages. The statement that the "suit and tie" straitjacket will
> never win out, however, just isn't true. The suits and ties invariably
> get control of any situation they find it useful to control :-(. It's
> a sad by-product of our economic system.
SCO UNIX System V/386 r3.2 does not have a 'BUGS' section for its
entries, (as far as I can tell). The man page for units is made up
of sections called: Name, Syntax, Description, and Files. It is
clear and sensibly written, and gives no disclaimer about exchange
rates. (Although Morgan Stanley is not likely to base financial plans
on the 1.7187 dollars/pound conversion it contains...)
I think there is a bit of confusion about people's tailors and their
ideologies. I was a long hair math professor and strenuously objected
to the BSD 4.2 man pages (and lots else about that calamity) and
now I work for an investment firm (still have the long hair, but do
wear suits) and have the same ideas about man pages. In the same
department as I work, there are some UNIX guru types, and they all
wear suits, have long or short hair according to taste, but most of
them think BSD man pages are cool. Most of them wear better suits than I do.
We all work for Morgan Stanley. (Can't get more Wall Street than that.)
So what's the point?
There are several types of programmers in the UNIX environment. Some,
like myself, are programmers by dint of skill in another professional
field - (numerical analysis, algorithmic complexity and applied math
in my case) - and some are UNIX/C natives. The natives find all the
little quirks familiar and no big deal, and appreciate the odd bit of
askance humor in the man pages. The OS/language itinerants find all
matters of operating system obstuctional, and language inadequate,
and can't seem to understand what was so sensibly constructed in
OS-A/Lang-I is so idiotically tied to history in OS-B/LANG-II.
UNIX/C natives are not particularly more or less sensitive to the
observations of the itinerants than are say the MVS/APL2 natives,
or the VMS/Pascal natives, or the NOS/FORTRAN natives, etc., (at
least in my experience) but they are somewhat more entrenched in
the condenscending attitude that theirs is the most advanced world
with the best stuff and no need to think about incorporating the
other world's better ideas into their future. Well, every itinerant
knows full well that what's hot today is just that... hot today.
Tomorrow will bring another OS and another language. The itinerants
will move on, and some of the natives will, too. Lots of the natives
will continue to fight the battles that their OS or language already
won, and this rear guard action is the source of the worst bigots.
Personally, I can see that the past six years have been good to
UNIX. It used to be a rickety monolingual child with dreadful bugs,
but now it's graduated to being a second-rate operating system, like
everything else. (I ain't seen a first-rate OS yet...) C has grown into
a definite language, but by finalizing some of it's more painful
mistakes. It'll stick around like FORTRAN, but I'll look elsewhere
for the future. UNIX/C will have it's day, but I'll be surprised if
C's "market share" isn't seriously threatened by languages which
benefit from more modern thinking in the next five years.
Later,
Andrew Mullhaupt
Brad Templeton
daily postings of the currency quotes to clari.biz.finance to 'units' format
and put them on the end of the unittab each day.
A simple news sys line entry can pipe all articles in that group. Here is
a free sample of Thursday's quotes for those who want to update their
unittab file right now.
From: clar...@clarinet.com
Newsgroups: clari.biz.finance
Subject: Foreign Exchange Rates 3-8
Keywords: foreign exchange, money
Date: 8 Mar 90 22:38:02 GMT
Lines: 83
ACategory: financial
Slugword: forex
Priority: regular
Format: regular, close
_ F_ O_ R_ E_ I_ G_ N _ E_ X_ C_ H_ A_ N_ G_ E
NEW YORK (UPI) -- Foreign Exchange interbank buyer rates and
foreign currency equivalents, provided by American Security Bank, Washington,
D.C. Retail transactions provide fewer units of foreign currency per
dollar.
U.S.$ Currency
Equivalent Per U.S. $
Thu Wed Thu Wed
Argntn austrl .000212 .000190 4720.00 5270.00
Australia dlr .7609 .7603 1.3142 1.3153
Austria schill .0836 .0834 11.96 11.99
Belgium frnc-c .0283 .0282 35.32 35.42
Belgium frnc-f .0283 .0283 35.36 35.35
Brazil cruzado 0.0294 0.0303 34.0000 33.0000
Britain pound 1.6390 1.6450 0.6101 0.6079
Britain 1-mo 1.6494 1.6358 0.6063 0.6113
Britain 3-mo 1.6123 1.6184 0.6202 0.6179
Britain 6-mo 1.5865 1.5925 0.6303 0.6279
Canada dollar .8472 .8455 1.1803 1.1828
Canada 1-mo .8439 .8420 1.1850 1.1876
Canada 3-mo .8462 .8357 1.1817 1.1966
Canada 6-mo .8294 .8272 1.2057 1.2089
Chile peso-f .003509 .003511 285.01 284.79
China yuan .2378 .2378 4.2050 4.2050
Colombia pes .002218 .002221 450.85 450.28
Denmark krne .1534 .1528 6.5195 6.5435
Ecudr sucr-z .001407 .001407 710.82 710.82
Egypt pound .3841 .3855 2.6037 2.5937
Finlnd mrkka .2498 .2496 4.0030 4.0060
France franc .1740 .1742 5.7455 5.7405
France 1-mo .1738 .1739 5.7547 5.7499
France 3-mo .1731 .1732 5.7772 5.7728
France 6-mo .1721 .1722 5.8105 5.8058
Greece drach .006239 .006235 160.29 160.39
Hollnd guildr .5227 .5226 1.9130 1.9135
HongKong dlr .1280 .1280 7.8122 7.8100
India rupee .0589 .0589 16.97 16.97
Indo'sa rupia .000554 .000554 1805.00 1805.00
Iran rial .0142 .0142 70.30 70.30
Iraq dinar 3.2446 3.2446 0.3082 0.3082
Ireland punt 1.5680 1.5662 0.6378 0.6385
Israel shekel .5051 .5051 1.9800 1.9800
Italy lira .000797 .000798 1254.75 1253.00
Japan yen .006621 .006656 151.03 150.25
Japan 1-mo .006627 .006661 150.90 150.12
Japan 3-mo .006638 .006672 150.64 149.88
Japan 6-mo .006652 .006685 150.32 149.58
Jordan dinar 1.5076 1.5076 0.6633 0.6633
Kuwait dinar 3.4329 3.4329 0.2913 0.2913
Lebanon pnd .001837 .001837 544.35 544.35
Mexico pes-z .000365 .000365 2742.00 2742.00
N.Zealand dlr .5885 .5875 1.6992 1.7021
Norway krne .1524 .1520 6.5625 6.5775
Pakistn rupee .0472 .0472 21.18 21.18
Peru inti .000074 .000073 13590.0 13790.0
P'pnes peso-z .0453 .0453 22.06 22.06
Portugl escd .006699 .006689 149.28 149.49
Saudi riyal .2668 .2668 3.7480 3.7480
Singapore dlr .5342 .5333 1.8720 1.8752
S.Africa rand .3882 .3886 2.5760 2.5735
S.Korea won .001451 .001454 688.99 687.70
Spain peseta .009165 .009122 109.11 109.63
Sweden krona .1624 .1618 6.1575 6.1790
Switzrl franc .6633 .6669 1.5075 1.4995
Switzrl 1-mo .6631 .6667 1.5081 1.5000
Swirzrl 3-mo .6626 .6662 1.5093 1.5011
Switzrl 6-mo .6616 .6664 1.5115 1.5005
Taiwan dollar .0385 .0385 25.98 25.96
Turkey lira .000415 .000416 2412.00 2406.00
UAE dirham .2725 .2725 3.6700 3.6700
Urug'y peso-z .001181 .001181 847.00 847.00
Venez bolivr-z .0238 .0238 42.01 42.01
W.Ger Mark .5882 .5884 1.7000 1.6995
W.Ger 1-mo .5884 .5886 1.6994 1.6990
W.Ger 3-mo .5883 .5885 1.6997 1.6991
W.Ger 6-mo .5875 .5876 1.7020 1.7017
Yugosl dinar 0.0857 0.0855 11.67 11.69
------
c-Commercial; f-Financial; z-Floating; x-N.Y. Money Market.
Interbank Buyers Rates
Source: American Security Bank, Washington, D.C.
--
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
David H. Thornley
>... Maybe we should all get MBA's while we are at it. Hey,
>lets all take up COBAL, there is no way in h*ll that you can have
>a flippant approach to ANYTHING in COBAL :-)
Actually, COBOL is a great language to be flippant in. It's just that all that
typing *all* *those* *words* makes most people to numb to be flippant. COBOL
forces many things to be named that really don't need names, so you are free to
name your work files after old girl friends or favorite flavors of ice cream.
Also, the English-like sequence makes it easy to write things like GO TO HELL
and ADD GIN VERMOUTH GIVING MARTINI as part of a valid program. You can
also have identifiers up to 31 characters long (unusual for a 50s language!)
with hyphens for spaces, so you can get all sorts of strange names. (Not that
I recommend all this in practice, you understand, but flippancy has kept me
sane through long system designs.)
We seem to be getting away from C, so I'm going to try to direct followups to
alt.cobol.
DHT
George W. Leach
>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