Collective memory

[Charles Richmond]

Walter Bushell wrote:
> 
> Charles Richmond <richmond at ev1.net> wrote:
> <Snip>
> > int  *p, x, y;
> >
> > then:
> >
> >     y = x/*p;
> >
> > is quite different from:
> >
> >     y = x / *p;
> >
> > The first way, "/*" will begin a comment...the second way,
> > you get the integer "x" divided by the integer pointed to by "p".
> 
> Ouch!! That is one reason code coloring is *important*.
> 
> I remember working in Fortran and being confused why the compiler was
> not accepting the if statement, 'til we looked at the cards and saw it
> was  a "1F" statement.
>
In the later part of our IBM/370 assembly language class, a girl
was running the program she wrote for her assignment. One statement
did *not* seem to do anything. She spend at least 30 minutes trying
to figure out what was wrong. Turns out that there was a "*" in 
column one, and the statement was really a comment...and generated
*no* code.

This happened because she was punching her program on good ole' 80
column cards, in a student environment where many people used the
same keypunch machines. Often people would pick up the "blank"
cards and stick them back in the input hopper for the keypunch.
It was easy to miss the "*" punched in column one, because the upper
left corner of the cards was sliced off by design. So the unlucky
girl just happened to get a card that *already* had a "*" in column
one, when she punched up her program. Instant bug...

Another favorite beginner mistake was punching code past column 72
in FORTRAN IV. Sometimes, if you were unlucky, the FORTRAN code
would make sense *without* the part beyond column 72. Of course,
the results would *not* be what was expected.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+