Re: Integers and standard

Richard Maine wrote:
(snip)

One I recall with some horror was from some of the simulation area at
Dryden (lots of tales of coding horror from there). They had some code
that was intentionally passing double precision real actual arguments to
single precision dummies. They weren't even aware that this assumed
anything special about but patterns. They thought that the compiler was
doing something "smart" to make this work. Instead, the compiler was
doing its usual (for f77 separate compilation) thing of blindly assuming
that the user was doing it right, while the users were assuming that the
compiler was making it all work.

Don't try that one at home, folks. At least not on any machines you are
likely to have at home... or probably at work either. It worked for the
floatting point representations of that machine, but it doesn't work (by
about 300 orders of magnitude) for most machines. All that code had to
be fixed when the sim lab got new computers.

It works for S/360 and successors, but not many others that
I can think of. (I have a P/370 so I can try it at home.
Hercules users can also try it at home.)

This is also one of my arguments against little-endian byte
ordering. That is, it causes programs to seem to work right
passing integers of the wrong size by reference.

How about an example the other way? Some years ago in a
discussion here I finally found how VAX/VMS Fortran passed
character constants to non-CHARACTER dummy variables.
Character variables are passed by descriptor, other scalar
variables by reference. The compiler and linker arrange to
fix it up at link time such that it works!

But I was arguing for negative hex constants even if the
bit pattern wasn't known. Though given the rarity of
ones complement machines, and that the ones I do know
of are 36 bits or more, a 32 bit hex constant would
give the right bit pattern on all machines.

Even so, it has to give the right answer to bitwise
operations, even on non-binary machines.

-- glen

.

Quantcast