RE: Making sense of 4-byte binary fields

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> 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.

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)

You'll very often see people use macros like "#define int32_t int" simply 
because as you go from platform to platform, the meaning of "int" changes, 
and rather than change their code, they just change the macros...

Then, of course there are systems like autoconf designed to detect all of 
these settings and allow you to write portable code... or libraries like 
GLIB that have them all set up for you...

The point is, there are lots of workarounds because "int" doesn't have a 
consistent meaning.  If C had been designed so that it always meant the 
same thing, there wouldn't be so much screwing around with it.

That's one (of many) advantages that RPG IV has over C.


> I still find myself calculating the number of bits in an API 4 B to 
> figure out what to use in RPG. (I know, I should have memorized it by 
> now.)

Nearly everything in the APIs is the same... always "10I 0" in RPG or 
"int" in C. Only when there's an exception do you have to stop and think 
about it :)

> It's no worse than having to deal with passing other data types that
> don't exist in RPG to another language.  We probably need the DWIM
> paramater passing convention.

Isn't that what programmers are for?  To translate what a user means 
(never what he/she says) into the code required by the computer?  If the 
OS had DWIM routines we'd be out of a job.