Language pitfalls (was Re: FORTRAN bug)

Language pitfalls (was Re: FORTRAN bug)

[Bob Kitzberger]

Experienced C programmers have rules of thumb that they follow in order
to help them to avoid language "problems".  Ada programmers also have
rules of thumb to help them avoid language "problems".  If you were to
list the top five C rules of thumb, they'd be something like:

	1. Use conditional preprocessor directives in .h files to avoid
           multiple file inclusions (oops!  That's a C preprocessor rule ;-)
 	2. Always use curly braces in conditionals
	3. Be careful to use '==' when you mean it, instead of '='
	4. Always malloc one more byte then your array length for strings
	5. Always use 'break' in each switch case, unless you really mean it

The top five rules of thumb for Ada are probably something like:

	1. Don't get carried away using tasks as units of decomposition
	2. Don't use the predefined types; define your own types
	3. Use packages as units of decomposition.
	4. Use private types to hide implementation details
	5. Avoid the USE clause; consider RENAMES instead.

Note that the Ada rules of thumb are more geared towards programming
in the large, and reflect the fact that the Ada programmer spends less
time on annoying *run-time* syntax glitches (*), and more time on
encapsulation and decomposition issues.

	.Bob.

(*) Of course, Ada programmers spend more time with compile-time syntax
    errors than anyone else ;-)
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: Language pitfalls (was Re: FORTRAN bug)

[enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!news.lth.se!dag]

In <comp.lang.ada> rlk@VisiCom.COM (Bob Kitzberger) writes:
>Experienced C programmers have rules of thumb that they follow in order
>to help them to avoid language "problems".

I also think we can close this discussion now.

Anyone interested in the problems of C should read the following
excellent book:

	Andrew Koenig: C Traps and Pitfalls, Addison-Wesley.

Dag Bruck

Re: Language pitfalls (was Re: FORTRAN bug)

[David Emery]

Maybe we should follow up Bob K's 5 rules and construct a "The Net":
Ada Traps and Pitfalls.  At least this will be a technically oriented
discussion on Ada, rather than Comp.Lang.Jihad.

I'll think about it and send in some of my rules.

				dave

Re: Language pitfalls (was Re: FORTRAN bug)

[Michael Feldman]

In article <252@visicom.com> rlk@VisiCom.COM (Bob Kitzberger) writes:

[good stuff deleted]
>
>(*) Of course, Ada programmers spend more time with compile-time syntax
>    errors than anyone else ;-)

I think this is _almost_ right. In my experience, the difficulty is
not with _syntax_ (are the structures formed correctly?) but with
_semantic checking_ (do the types match?). Both are compile-time
issues. In my experience with everyone from freshmen to experienced
industry folks, the pure syntax problems go away after a few weeks of
coding; the semantic ones never do. Ada's type system is complicated,
powerful, and designed to be _very_ safe, and therefore the type
checking is a pain in the neck to get through the compiler.

It should come as no surprise to regular readers of my junk that I think
it's worth it.

Mike Feldman

PS - the semantic checking is harder to write into the compiler, too!

Re: Language pitfalls (was Re: FORTRAN bug)

[Richard Pattis]

Since Dave has volunteered to keep track....

When I introduce recursion in my CS1/CS2 class, this one never fails to show
up. It is truly a C-like error (excuse the pejorative term) in that the
distinction between a statement and value is clouded to reduce the number of
reserved words.

Often the base case of a recursive function to manipulate a list looks like:

  IF mumble = NULL THEN
    RETURN NULL;
  ELSE ...

What my students sometimes write is

  IF mumble = NULL THEN
    NULL;
  ELSE ...

Here the statement NULL replaces the returning of a NULL value (which might be
better to denote as NIL, at the expense of another reserved word). Of course,
this is all syntactically legal and the error shows up only at execution time:
often as a PROGRAM_ERROR (so at least Ada catches it at some time) if there
are no other statements after the IF in the function. Of course, some compilers
will give a warning based on the functions data flow information.

Rich Pattis
-- 
------------------------------------------------------------------------------
  Richard E. Pattis                     "Programming languages are like
  Department of Computer Science         pizzas - they come in only "too"
    and Engineering                      sizes: too big and too small."

Re: Language pitfalls (was Re: FORTRAN bug)

[news.centerline.com!noc.near.net!inmet!spock!stt]

In article <1992Dec15.180821.17817@beaver.cs.washington.edu> 
  pattis@cs.washington.edu (Richard Pattis) writes:

> . . .
>Often the base case of a recursive function to manipulate a list looks like:
>
>  IF mumble = NULL THEN
>    RETURN NULL;
>  ELSE ...
>
>What my students sometimes write is
>
>  IF mumble = NULL THEN
>    NULL;
>  ELSE ...
>
>Here the statement NULL replaces the returning of a NULL value (which might be
>better to denote as NIL, at the expense of another reserved word). . . .

Oh boy.  That is a nasty one.  This argues for a "friendly" 
Ada compiler giving a warning about any use of "null;" other
than the idiomatic ones like "when others => null;" or "begin null; end;"
(especially in a function that returns an access type ;-).

In retrospect, one could argue that it would have been better
to have no "null" statement at all (other than simply ";") than
to create a situation allowing this kind of one word error.

>Rich Pattis

S. Tucker Taft    stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Language pitfalls (was Re: FORTRAN bug)

[Robert I. Eachus]

In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet.c
om (Tucker Taft) writes:

   Oh boy.  That is a nasty one.  This argues for a "friendly" 
   Ada compiler giving a warning about any use of "null;" other
   than the idiomatic ones like "when others => null;" or "begin null; end;"
   (especially in a function that returns an access type ;-).

   In retrospect, one could argue that it would have been better
   to have no "null" statement at all (other than simply ";") than
   to create a situation allowing this kind of one word error.

    Actually, there is an Ada rule which normally catches this, and
which Robert Dewar and I have argued should be removed in Ada 9X.  (A
function must contain a return statement RM 6.5(1).)  If it belongs on
the top ten list, then the rule should stay.

    (What Robert Dewar and I objected to was that certain functions
whose only intended effect is to raise an exception must still contain
a return statement.  This results in junk return statements in stubbed
out code, and makes a stubber much harder to write.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Language pitfalls (was Re: FORTRAN bug)

[crispen]

visicom!rlk@nosc.mil  (Bob Kitzberger) sez:

>	5. Avoid the USE clause; consider RENAMES instead.

Why the heck are people teaching this?  I mean, do you really *like*
code that looks like:

         if ((Environment_Messages.Mode_Selection_Message_Record.
            Age_Of_This_Message = Application_Layer_Services.New_Message) and
            (Environment_Messages.Data_In_Mode_Selection_Message_Record.
            Modules_Affected (Global_Types.Environment) = Global_Types.On))
          then

or whatever?  And don't forget this crap that you have to put at the
beginning:

   function "=" (L, R: Application_Layer_Services.Message_Ages) return Boolean
      renames Application_Layer_Services."=";

The above (well, slightly less awful -- I cheated and have a package-
body-scope USE clause for Global_Types and I have a constant RENAMES
for New_Message) is from actual production code, but remember,
I have no life ;-)

Nobody who is interested in getting the job done and getting out of
the office at the end of the day is going to want to write (or read)
code that looks like this.  Result?  192 USE clauses in every package
body "just to get it going".  But somehow there's never time to
rework those bodies.

Isn't it better instead to teach the locally scoped USE clause:

	 declare                           -- for the following IF
           use Environment_Messages;       -- Mode_Selection_Message_Record
           use Application_Layer_Services; -- Message_Age
           use Global_Types;               -- Mode_Sel..Record types
         begin
            if ((Mode_Selection_Message_Record.
               Age_Of_This_Message = New_Message) and
               (Data_In_Mode_Selection_Message_Record.
               Modules_Affected (Environment) = On))
             then
               ...
            end if;
         end;

Why isn't this being taught?  Was it at one time broken in the holy
VAX Ada?  Or is there some other reason I'm not thinking of?

BTW, to forstall a possible objection about scoping it over a 2-page
IF, I personally believe that if you have a 2-page IF, you've got
a more serious problem than just a hard-to-read USE clause!

p.s., sorry about the look of the IF statement; old FORTRAN habits
die hard.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Language pitfalls (was Re: FORTRAN bug)

[olivea!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!asuvax!ennews]

In article <EACHUS.92Dec15202249@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet.
com (Tucker Taft) writes:
>
>   Oh boy.  That is a nasty one.  This argues for a "friendly" 
>   Ada compiler giving a warning about any use of "null;" other
>   than the idiomatic ones like "when others => null;" or "begin null; end;"
>   (especially in a function that returns an access type ;-).
>
>    Actually, there is an Ada rule which normally catches this, and
>which Robert Dewar and I have argued should be removed in Ada 9X.  (A
>function must contain a return statement RM 6.5(1).)  If it belongs on
>the top ten list, then the rule should stay.

The "null;"/"return null;" was a problem with the base case in a
recursive function (null is overloaded, and even worse it's an
expression *and* a statement - isn't that something we hate about
C :).  This implies there will be additional returns somewhere in
the routine and it will not be caught by the compiler.  The real
problem is that there exists an execution path that can lead out
of the function without encountering a return.  And, won't Ada
catch this at run-time?  Granted it would be nice for the language
to catch it at compile time, but the compiler could easily print a
warning saying that such a path exists.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Language pitfalls (was Re: FORTRAN bug)

[Mark A Biggar]

In article <EACHUS.92Dec15202249@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet.
com (Tucker Taft) writes:
>   Oh boy.  That is a nasty one.  This argues for a "friendly" 
>   Ada compiler giving a warning about any use of "null;" other
>   than the idiomatic ones like "when others => null;" or "begin null; end;"
>   (especially in a function that returns an access type ;-).
>   In retrospect, one could argue that it would have been better
>   to have no "null" statement at all (other than simply ";") than
>   to create a situation allowing this kind of one word error.
>    Actually, there is an Ada rule which normally catches this, and
>which Robert Dewar and I have argued should be removed in Ada 9X.  (A
>function must contain a return statement RM 6.5(1).)  If it belongs on
>the top ten list, then the rule should stay.
>    (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement.  This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)

How about a rule that requires a function to contain either a return or an
explisit raise statement?  Would that not satisfy both sides?

--
Mark Biggar
mab@wdl1.wdl.loral.com

Re: Language pitfalls (was Re: FORTRAN bug)

[Bob Kitzberger]

eachus@oddjob.mitre.org (Robert I. Eachus) writes:

>    (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement.  This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)

Robert, I can't think of a reason to have a function that does nothing
but raise an exception... can you provide an example?  (I'm not
questioning the need for it -- just curious)

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: Language pitfalls (was Re: FORTRAN bug)

[Julian C . Lander]

In article <256@visicom.com>, rlk@VisiCom.COM (Bob Kitzberger) writes:
|> eachus@oddjob.mitre.org (Robert I. Eachus) writes:
|> 
|> >    (What Robert Dewar and I objected to was that certain functions
|> >whose only intended effect is to raise an exception must still contain
|> >a return statement.  This results in junk return statements in stubbed
|> >out code, and makes a stubber much harder to write.)
|> 
|> Robert, I can't think of a reason to have a function that does nothing
|> but raise an exception... can you provide an example?  (I'm not
|> questioning the need for it -- just curious)
|> 

I didn't write this one, but it is in some code I'm using.
The situation is interface with C-language functions, which return
error codes.  The chunk of code before me (I don't know a good noun
for what it is--it builds about 3 different executables) has a function
called Raise_Appropriate_Exception, which raises the exception 
corresponding to the return code it has been passed.

Since it never gets a 0 (its caller should avoid that), it doesn't return.

I don't know that it's the best solution to the problem (I'm not wild
about it, frankly), but that's what I have.

Julian C. Lander
jclander@mitre.org

Re: Language pitfalls (was Re: FORTRAN bug)

[John Bollenbacher]

Harry Koehnemann (koehnema@enuxha.eas.asu.edu) wrote:
: In article <EACHUS.92Dec15202249@oddjob.mitre.org> eachus@oddjob.mitre.org (R
obert I. Eachus) writes:
: >In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inme
t.com (Tucker Taft) writes:
: >
: >   Oh boy.  That is a nasty one.  This argues for a "friendly" 
: >   Ada compiler giving a warning about any use of "null;" other
: >   than the idiomatic ones like "when others => null;" or "begin null; end;"
: >   (especially in a function that returns an access type ;-).
: >
: >    Actually, there is an Ada rule which normally catches this, and
: >which Robert Dewar and I have argued should be removed in Ada 9X.  (A
: >function must contain a return statement RM 6.5(1).)  If it belongs on
: >the top ten list, then the rule should stay.
: 
: The "null;"/"return null;" was a problem with the base case in a
: recursive function (null is overloaded, and even worse it's an
: expression *and* a statement - isn't that something we hate about
: C :).  This implies there will be additional returns somewhere in
: the routine and it will not be caught by the compiler.  The real
: problem is that there exists an execution path that can lead out
: of the function without encountering a return.  

Seems to me the real problem is that there is a potential path out if the
function which does not raise an exception but has the 'wrong' value, e.g.
    if mumble = null then
      null;
    end if;
    ...
    return new mumble_ptr;
Thanks for pointing out this gotcha. I'd never seen it before.

--
-----------------------------------------------------------------------------
- John Bollenbacher                                        jhb@dale.cts.com -
- Titan Linkabit Corp.                                       (619) 552-9963 -
- 3033 Science Park Rd.                                                     -
- San Diego, Ca. 92121                                                      -
-----------------------------------------------------------------------------

Re: Language pitfalls (was Re: FORTRAN bug)

[Robert I. Eachus]

In article <256@visicom.com> rlk@VisiCom.COM (Bob Kitzberger) writes:

   Robert, I can't think of a reason to have a function that does nothing
   but raise an exception... can you provide an example?  (I'm not
   questioning the need for it -- just curious)

   Stubbing is the major reason for doing this, i.e. something not
available in the current version of the software, but the interface is
provided.

   Another case is where a generic requires an operation as a formal
parameter which is meaningless for a particular actual.  There are
cases where providing a function which raises an error is more useful
than rewriting the generic.  For example, assume you have a "standard"
interface to IO devices, for some current_position would return a
value, for other devices the function of the same name would
immediately raise an exception.

   A more subtle use in when you are not sure an obsolete interface
or object can be eliminated.  Putting in a function which prints a
meaningful message then returns is more polite than ripping it out,
and waiting until some user of the package screams.

   One more use I have found was for a private type where user created
objects were verboten.  (Put in a component with such a function as
the default initial value.  User created objects will cause the
function to be evaluated.)

   Lots of uses, but only the difficulties the rule creates in
stubbers is compelling.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Language pitfalls (was Re: FORTRAN bug)

[Terry J. Westley]

In article <EACHUS.92Dec15202249@oddjob.mitre.org> eachus@oddjob.mitre.org (Rob
ert I. Eachus) writes:
>    Actually, there is an Ada rule which normally catches this,

["this" refers to substituting "null" for "return null" by mistake]

>and
>which Robert Dewar and I have argued should be removed in Ada 9X.  (A
>function must contain a return statement RM 6.5(1).)  If it belongs on
>the top ten list, then the rule should stay.
>
>    (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement.  This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)
>
>--
>
>					Robert I. Eachus

Many compilers produce a warning for such a situation.  IMHO, this is
good but doesn't go far enough.

I hate compiler warnings; I will typically do anything to eliminate them
because I done't want to keep rereading the same warnings every time a unit
is compiled.  Sometimes, they cannot be eliminated as in the example above.

I would like to have the ability, perhaps with a pragma, which allows me to
tell the compiler that I know a certain statement will raise a warning of
a certain class and to suppress the warning.  This must be done on a statement
by statement (really warning by warning) basis.  Turning off all the warnings
is too dangerous.  They really are useful.

Have any compiler gurus considered this?

-- 
Terry J. Westley, Principal Computer Scientist
Calspan Corporation, P.O. Box 400, Buffalo, NY 14225
westley@calspan.com
Let's hear it for smart mailers that cut off long signa

Re: Language pitfalls (was Re: FORTRAN bug)

[John Halper]

In article <EMERY.92Dec15095542@dr_no.mitre.org> emery@dr_no.mitre.org (David E
mery) writes:
>Maybe we should follow up Bob K's 5 rules and construct a "The Net":
>Ada Traps and Pitfalls.  At least this will be a technically oriented
>discussion on Ada, rather than Comp.Lang.Jihad.
>
>I'll think about it and send in some of my rules.
>
>				dave

Good idea, how about a moderated group.  I sure would like to be able to
read technically oriented discussions without having to wade through all
the crud.  Mind you I would never suggest suppressing the ever witty Fred
and Ted show. I just want to be able to turn to another channel.
J. Halper