🚀 go-pugleaf

In article <DM0BCt.JEE@cix.compulink.co.uk> Mark Morgan Lloyd,
mark_tbu@cix.compulink.co.uk writes:
>I always read PIM to mean that a type transfer was a straight bit-by-bit 
>mapping, while the VAL() (and, for that matter, ORD()) operations could 
>include other transforms. After using Logitech and FTL it came as a bit 
>of a shock to find that JPI were different, and their occasionally 
>arrogant attitude did not help them one bit.

I remember seeing that (I now swivel my chair to the PC ...).

Yapp - in the file \TS\DOC\OS2_M2.DOC (this is 3.10 extended environment):

...
3.  ERRATA
==========
...
Reference manual p 43:

    A type transfer function is considered well-behaved if the sizes
    of the transfer type and the value type are the same, or if a
    proper VAL conversion is performed. If the value type size is more
    than the transfer type size then the remaining last bytes of the
    value are ignored. If it is shorter, the last bytes of the resulting
    value are undefined.
...

So I think this means that if you do (assuming varaible names is
type description): 

   card := CARDINAL(int);  or   int := INTEGER(card);

the bit-pattern is simply looked upon another way and it works as
intended in PIM (e.g. CARDINAL(-1) = MAX(CARDINAL) ) and I have never
had any problem converting between BITSETs and CARDINAL nor e.g. defining
a 32-bit LongBITSET and convert it to a LONGCARD which is handy for
some Windows flagsets.

However, since also CARDINAL(real) is allowed one has to think about it
since 2 bytes are truncated or with CARDINAL(byte) where one byte will be
undefined. Best avoided - but I see it used at places in TS sample code.

However, I also remember reading somewhere that a () actually *does*
proper value conversion but *that* docs I can't find now. 

What it all boils down to with TS is that if you only use () for types
with the same sizes there are no problems it does what PIM says, and use
VAL(,) for the rest or the special functions such as TRUNC() where
appropriate. Following these reasonable rules I have had no surprises.

Just because it is an extension, one does not have to make use of it.

The proposed ISO standard using CAST(,) is clear. Even if it clutters 
the code, it is good to be able to spot type transfers easily since many 
odd bugs originate from those. With Windows code there is always *a lot
of* type transfer where 32-bit message parameters are constanty to be
reinterpreted as various pointers, adresses, two words together etc.

Regards

.......................................................................
Bengt-Inge Dalenback                                   
Department of Applied Acoustics        
Chalmers University of Technology    
Gothenburg, SWEDEN                  
e-mail: bid@ta.chalmers.se