Re: Making sense of 4-byte binary fields

["James H. H. Lampert" <jamesl@xxxxxxxxxxx>]

In response to:
> > I think you have a good point about the misleading documentation.  Most
> > other languages specify the integer types by names--e.g. short, int,
> > long...and leave the number of bits to the implementation.  Fortunately,
> > it's mostly standardized.

Scott Klement wrote:
>  Actually, that has caused a lot of problems. Particularly on Unix systems
> where you typically want to write code on one system, but expect it to
> compile and run on many completely different ones (including completely
> differnt hardware architectures)

Scott's right about the woes of leaving the number of bytes various
names mean up to the implementation, but that's hardly confined to Unix,
Linux, Aix, &c. It's a problem with ALL implementations of C. That's why
Sun made it an inflexible standard in Java.

Java has it right, at least in terms of consistency, although you have
to RTFM to know that "int" is always 4 bytes, "short" and "char" are
always 2, and "long" is always 8. Typical coffee-crazed C-jockey
thinking. Oh, if Java had only been designed by a lover of PL/I. . .

But FORTRAN had it right a long time ago, with INTEGER*2 and INTEGER*4.
Just as PL/I had it right a long time ago with BIN FIXED (15,0) for a
2-byte (15 bits + sign, get it?) integer, and BIN FIXED (31,0) for a
4-byte integer. And of course, MI got it right with explicitly giving
the number of bytes, almost the same way as Fortran.

Anybody have any idea what the RPG designers were smoking when they
decided to make it the number of decimal digits, and to actually
generate the extra code to clamp it to that specified number of decimal digits?

-- 
James H. H. Lampert
Professional Dilettante
http://www.hb.quik.com/jamesl
http://members.hostedscripts.com/antispam.html
http://www.thehungersite.com

Help America's Passenger Trains. http://www.saveamtrak.org

Read My Lips: No More Atrocities!