comp.lang.ada
 help / color / mirror / Atom feed
* Why I like Ada
@ 2004-05-22  0:39 Fionn mac Cuimhaill
  2004-05-22 14:11 ` Per Dalgas Jakobsen
  0 siblings, 1 reply; 20+ messages in thread
From: Fionn mac Cuimhaill @ 2004-05-22  0:39 UTC (permalink / raw)


I found this in a signature in a message in another newsgroup. I don't
know if Stroustrup actually said this, but it's true and funny.
> "C makes it easy to shoot yourself in the foot;
> C++ makes it harder, but when you do it blows
> your whole leg off."
> - Bjarne Stroustrup




^ permalink raw reply	[flat|nested] 20+ messages in thread
* Why I like Ada
@ 1994-12-02  9:44 Richard A. O'Keefe
  0 siblings, 0 replies; 20+ messages in thread
From: Richard A. O'Keefe @ 1994-12-02  9:44 UTC (permalink / raw)


When I printed the master copies of my exams for our recently past exams,
they were shifted down on the page.  I hadn't changed my (LaTeX) formats.
I didn't know whether to blame LaTeX, the a4wide.sty file (which was now
mysteriously aliased to the a4.sty file for some reason), something else
in the TeX software proper, dvitops, the laserprinter it was sent to, or
some configuration file totally beyond my ken.  (I've since been told it
is most likely the latter, but our technical support group having been
downsized to the point where there isn't really enough worker time left
to read problem reports, let alone do anything about them, well, I guess
I'll have to live with the problem for a while.)  One thing I thought of
doing was to try another formatter.

There's another formatter which I had long wanted an excuse to try.  It
has a lot of nice ideas.  The design has been published in the technical
literature; the project in question has been running for ~10 years; it's
actively supported; there's a mailing list for help; and if I FTPed it
the sources would be under *my* control so that nobody else would tamper
with key files.

Of course, the sources are written in C.  43 *.c files.  One .h file with
everything in it.  25 000+ lines.  Not a very big program.  So I edit the
Makefile to tell it where I want things put, and make one change that had
not occurred to the author: I added "-Wall" to the gcc command line.  OW!
After about two weeks of spare time tweaking (putting 'static' here 'void'
there, a prototype in the other place, really minor stuff) I finally have
it to the point where there are about 300 lines of output from Lint (that
is a huge improvement, let me tell you).

Fairly obvious point number 1:  about 100 of those lines warn that the
ANSI C rules for mixed signed/unsigned arithmetic are DIFFERENT from the
traditional K&R/pcc/UNIX rules for mixed signed/unsigned arithmetic, and
that this may have affected line so-and-so.  I have no idea how many of
the warnings are genuine, BUT THE AUTHOR WASN'T SEEING ANY OF THEM because
he wasn't using gcc -Wall or lint.

Interestingly enough, while I was composing this message I decided to try
to do something about those 100 lines.  It turns out that *most* of them
are benign (lint warning that "x > 0" is suspicious) but lurking amongst
them are
    - several where a group of variables having the same *abstract*
      type (count-of <thing>) have been given different *concrete*
      types (some int, some unsigned char, some unsigned short &c)

    - a couple of places where potentially serious range problems were
      lurking (e.g. a count being stored in an unsigned char, with not
      even a comment in the code to ensure that there are at most 255
      things to count, and some reason to suspect there might be more)

    - code that doesn't make sense unless 'int' is exactly 32 bits.

The interesting points here are that
    - the C tools (gcc -Wall and lint) *can* find some dangerous things,
    - the normal sloppiness of the compiler means that the original
      author was encouraged to develop a style in which genuine warnings
      (had he ever asked for them) would have been swamped
    - I am getting *extremely* nervous about this program; there is
      NO connection in the code between the bounds of the many ranges
      and the declared concrete types of the variables.
    - The Ada approach of having lots of integer subtypes is clearly
      the right thing for this program.

Another problem is that gcc -Wall and lint both try to warn you about
variables that may be used without being initialised.  Neither of them
is very smart.  It turns out that all of the uninitialised variable
warnings are (or may be!)  bogus.  A fairly typical kind of pattern is
	p = ...
	while (...) {
	    x = ...
	    ...
	}
	... use x ...
which is ok *IF* the loop executes at least one time, typically if the
doubly linked list it traverses is non-empty.  As it happens, the code
is full of things that only make sense for non-empty lists, and rather
sparing of comments or assertions that would make me confident.  Lint
and gcc haven't found uninitialised variables, but they _have_ found a
maintenance problem.

When I got most of the warnings caused by sloppy style out of the way,
I found that a number of serious and potentially serious problems were
present, and gcc -Wall and lint found them.

(1) There is a really weird statement:

	    (p = chpt) - 1;

(2) There is a data type with range at least 0..520.  The values were
    being stored in unsigned char (0..255)!  Type a long enough word at
    this document processor, and BOOM!

    There is very good reason to believe that this is not the only
    wrong-size-for-range problem.  Unfortunately, because the C code
    uses unsigned types, it is "well-defined"; Procrustes rules!

(3) When it read a certain file, it was ALWAYS ignoring the result status
    of getc().  When it wrote that file (and others) it was ALWAYS ignoring
    the result status of putc() and friends.  I have lost enough data due
    to stupid utilities thinking that writes can never go wrong to be
    really annoyed about this.

Of these,
    (1) Ada simply would not allow this.
    (2) Ada lets you express the range you want, and have it checked.
    (3) Say what you like about TextIO, exception handling is easier
	to get right than dozens of if (... == -1) ... tests.

The author of this code was very concerned about quality and debugging.
The code is FULL of debugging tests.  If he had been able to write it in
Ada when he started the project, I'd have been saved 2 weeks of spare time,
and I'd have vastly more confidence in the result than I now do.

-- 
"The complex-type shall be a simple-type."  ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-06-02  5:13 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-22  0:39 Why I like Ada Fionn mac Cuimhaill
2004-05-22 14:11 ` Per Dalgas Jakobsen
2004-05-22 15:23   ` Preben Randhol
2004-05-22 16:27     ` Björn Persson
2004-05-25 21:29       ` Robert I. Eachus
2004-05-26  7:44         ` Peter Amey
2004-05-26  8:18           ` Ludovic Brenta
2004-05-26 16:15             ` Martin Krischik
2004-05-26 19:33               ` David Starner
2004-05-30 18:06                 ` Richard  Riehle
2004-05-30 18:17                   ` Randy Brukardt
2004-05-30 19:09                     ` Adrian Knoth
2004-05-31 13:27                     ` Björn Persson
     [not found]                   ` <inpkb0d57uiaf6970hk0ctj09orni4piea@4ax.com>
2004-05-31  2:07                     ` Richard  Riehle
2004-05-26 15:30           ` Wes Groleau
2004-06-01  3:57           ` Robert I. Eachus
2004-06-02  1:48             ` Jeffrey Carter
2004-06-02  5:13               ` Robert I. Eachus
2004-05-22 22:01   ` Wes Groleau
  -- strict thread matches above, loose matches on Subject: below --
1994-12-02  9:44 Richard A. O'Keefe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox